fix export crash test due to assert hit, tdf#61996 follow-up

Fallout of 88a7958984
Cause was a crappy number format that now is parsed differently and
results in UNDEFINED type, hence XMLTokenEnum was XML_TOKEN_INVALID
which later made assert(XML_TOKEN_INVALID < eToken) in
xmloff/source/core/xmltoken.cxx GetXMLToken() bail out.

Handle that during export and map to number-style.

An example of fdo82933-1.ods that triggered this is

[>0]" $"\"#"٬##0٫"00"٬"\";[<0]" $("\"#"٬##0٫"00);" $-"\"#"٬"\";@

Already import massively complained about
xmloff/source/style/xmlnumfi.cxx:1710: invalid number format
but not only for this format, the document contains a pile of crappy
stuff.

Possibly number format code scanning could be improved to type that
NUMBER instead, which it could be as only the #...00 and #...00) are
actually digit related, everything else are string constants. However,
that likely was not the intention of the document author..

Change-Id: I7c2b202b0b87e1a7fa7a9f56862a6bb7618ad9ff

xmloff/source/style/xmlnumfe.cxx

@@ -1008,7 +1008,14 @@ void SvXMLNumFmtExport::ExportPart_Impl( const SvNumberformat& rFormat, sal_uInt
     XMLTokenEnum eType = XML_TOKEN_INVALID;
     switch ( nFmtType )
     {
-        // type is 0 if a format contains no recognized elements
+        // Type UNDEFINED likely is a crappy format string for that we could
+        // not decide on any format type (and maybe could try harder?), but the
+        // resulting XMLTokenEnum should be something valid, so make that
+        // number-style.
+        case css::util::NumberFormat::UNDEFINED:
+            SAL_WARN("xmloff.style","UNDEFINED number format: '" << rFormat.GetFormatstring() << "'");
+            // fallthru
+        // Type is 0 if a format contains no recognized elements
         // (like text only) - this is handled as a number-style.
         case 0:
         case css::util::NumberFormat::EMPTY: