It's better to use two completely separate source trees than to try to
build two different versions of LibreOffice in the same one

Reduces the build time of the 'moz' module by 30% or so.

It might be a false negative, or something.

Adapt some of the DLL names to match conventions we currently use in a
MinGW build. If those are changed to be exactly like when built with
MSVC (for SDK ABI stability reasons), will have to change here, too.

Bypass stuff that we can't build with MinGW when necessary. Should be
synchronized with the corresponding makefiles, obviously. We can't
currently build the Explorer extension or MSI installer custom actions
with MinGW due to lack of some required headers and/or import
libraries.

Also remove mingwm10.dll stuff. That is an obsolete DLL not used by
current MinGW, says Fridrich.

XColorTable was the last class using this code and it's now based on
XPropertyList instead.

Surely these are linked to by default anyway? Is this just old cruft,
or specific to OOo's use of MinGW on Cygwin, and not needed with a
modern mingw-w64 cross-compiler? Let's see...

Make sure the MINGW_FOO environment variables get set and propagated
to the build environment also in the MinGW cross-compilation case. The
OOo code used to do that for MinGW natively on Windows (under
Cygwin). (Which we don't intend to support.)

Now, whether the *use* of these variables in the various makefiles etc
is relevant any more remains to be seen. I suspect all that might well
be unnecessary, as we after all are capable of cross-build the code
using MinGW just fine currently with none of these MINGW_FOO being
set.

One place where at least MINGW_GCCDLL and MINGW_GXXDLL is needed,
though, is in scp2. We presumably do want to include these DLLs (the
shared libgcc and libstdc++) in the installation set, to the extent
the scp2 stuff can be used still in a MinGW cross-build context.