Reduce scope of $packjobref.
Remove $exithandler and its shutdown check, since no handler was ever assigned.
Remove some unused install::global:: variables.

Define _HAS_ITERATOR_DEBUGGING as 0 so that we don't use the debugging
ordering predicates, which cause compilation errors thanks to the way
we use std::equal_range(). In this case it seemed fairly hairy to fix
that, so...

- Imports Legacy Text.
- Formatting info is not imported.

- Assumes axial gradient fills when more than 3 colors are present.
- Implements importing of Transparency Gradients.

MSVC refuses to compile otherwise.

Whether things actually work when pyuno is built against the debugging
runtime, but the internal Python (to the best of my knowledge) still
against the normal one, I don't know. But anyway, this makes the build
succeed here.

Take notice of USE_DEBUG_RUNTIME also in set_wntx64.mk.

Don't unset USE_DEBUG_RUNTIME and don't hardcode the non-debugging
msvcprt.lib when building the Explorer extension.

Undefine OSL_DEBUG_LEVEL in its source files that would otherwise drag
in the diagnosing functions from sal. We don't link the Explorer
extension with sal.

As such it might not make much sense to actually *use* a shell
extension built with assertions in the C++ library, against the
debugging C/C++ runtime. You don't want assertions to fire in
Explorer, do you? On the other hand, one could be debugging an
Explorer extension remotely. Maybe even locally, I don't know if some
lower levels of Windows get upset if Explorer is unresponsive due to
being debugged, or something.

But anyway, the main point for now is to make an --enable-dbgutil
build succeed.

Alternatively we could also make sure USE_DEBUG_RUNTIME is unset in
*all* makefiles in shell.

Besides, hardcoding msvcprt.lib breaks a dbgutil build where we use
msvcprtd.lib.

It doesn't make sense to try to use anything else to print on *nix
systems these days