...instead of using yet another local implementation of parsing media types.

CMimeContentType is the implementation of the UNO
css.datatransfer.XMimeContentType interface.  One observable change in behavior
is that type, subtype, and parameter names will now always be reported in lower
case instead of with the casing from the input preserved (but those differences
in casing are functionally equivalent per the media type specification).  Also,
parameter names supplied to the hasParameter and getParameterValue functions are
now also treated case-insensitive.

The upside of this change is that INetMIME::scanContentType (via "The encoding
of rMediaType should be US-ASCII, but any Unicode values in the range U+0080..
U+FFFF are interpreted 'as appropriate.'") already implicitly supports RFC 6532
"Internationalized Email Headers" extensions for media types, allowing quoted-
string parameter values to contain non-ASCII Unicode characters.

That means that tfd#120158 "Impossible to paste special in Writer from Calc in
Libreoffice 6.1.x in some UI languages - the dialogue caption says 'unknown
source'" can be fixed by just allowing non-ASCII typename parameters being
generated in ImplGetParameterString in svtools/source/misc/transfer.cxx, and
reverting the problematic (see the comments there) previous fix
<https://gerrit.libreoffice.org/61601> "tdf#120158: fix ImplGetParameterString
for typename".  (Which will be done in a follow-up commit, to ease potential
backporting, as that previous fix has already been backported to some versions
but not to others.)

Change-Id: I5d4d3586e8046f288a97605b000e262a8db5a4e9
Reviewed-on: https://gerrit.libreoffice.org/61684
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>