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.

It was supporting both XPropertyTable & XPropertyLis. XColorTable is now
based on XPropertyList and it was the only on that was based on the Table
class.

TODO: we might be able to remove some of the "if(mpList)" statements; this
needs more research.

I should have changed this in the "rebase patch".

The class is now based on XPropertyList instead of XPropertyTable and all
of the other classed based on XPropertyList are named X..List.

Despite these being marked as inline, needed when linking at least in
a WNTMSC build with --enable-dbgutil, possibly always with WNTMSC.