memory: Fix memory debugging with Windows threads

On Windows, malloc hooks can be called after the final call to
xmlCleanupParser in various tests. This means that xmlMemMutex can still
be accessed if memory debugging is enabled, so the mutex should not be
cleaned.

This also means that tests may report spurious memory leaks on Windows.

The old implementation avoided the issue by keeping track of all
global state objects in a doubly linked list, so they could be cleaned
during xmlCleanupParser.

But as far as I can tell all memory will be freed eventually, so this is
mostly an issue with our test suite.

python/tests/thread2.py

@@ -96,6 +96,9 @@ if failed:
 
 # Memory debug specific
 libxml2.cleanupParser()
+# Note that this can leak memory on Windows if the global state
+# destructors weren't run yet. They should be called eventually,
+# so this leak should be harmless.
 if libxml2.debugMemory(1) == 0:
     print("OK")
 else:

xmlmemory.c

@@ -878,7 +878,16 @@ xmlCleanupMemory(void) {
  */
 void
 xmlCleanupMemoryInternal(void) {
+    /*
+     * Don't clean up mutex on Windows. Global state destructors can call
+     * malloc functions after xmlCleanupParser was called. If memory
+     * debugging is enabled, xmlMemMutex can be used after cleanup.
+     *
+     * See python/tests/thread2.py
+     */
+#if !defined(LIBXML_THREAD_ENABLED) || !defined(_WIN32)
     xmlCleanupMutex(&xmlMemMutex);
+#endif
 }
 
 /**