so let's make the sal_intXY ugliness even a bit more ugly

This avoids comparison of raw values (ScDPItemData) during the 2nd sort.
Comparison of raw values can be expensive especially when the item sets mostly
consist of string values.

The old code relied on the order of initializing global static variables across
compilation units, which failed for MinGW cross compilation.  Cleaned up.

...as soffice.exe creates the proper environment (PATH) for soffice.bin to be
able to load URE libs like sal3.dll, so soffice.exe itself should neither be
able to load nor depend on sal3.dll (and does not depend on anything exported by
it, anyway).

It is unclear to me how this ever worked (which it presumably did?) with any
Windows build, either native MSVC or cross-compiled MinGW.  (Maybe MSVC builds
do not record a dependency from soffice.exe to sal3.dll, noting that the former
does not import anything from the latter?)

Or should it be --without-helppack-integration that affects it? Or
both? Why do we need both these switches?  And what does that
irritating "integration" thing mean again? Does
--without-helppack-integration mean "yes, do build helppacks, but
don't integrate them"?

libxslt in Fedora mingw packages depends on it.

Writer's default is 0, but Word's default is 26 (15 in 1/8 pt)

Otherwise code using the lcms2 we build won't get the stdcall
decorations and linking will fail.

Nah, will use the patch by Lubos instead.

This reverts commit 85f07455.