RFR: 8346195: Fix static initialization problem in GDIHashtable

[Magnus Ihse Bursie]

There has been a latent problem in `GDIHashtable` since time immemorial, but due to sheer luck it has not caused any issues for us. However, I managed to provoke it when I was doing some build changes.

This is the problem:
In `GDIHashtable`, there is a static field `GDIHashtable::BatchDestructionManager manager`, which is initialized in `GDIHashtable.cpp`.

In `AwtPen`, there is a static field `GDIHashtable cache`, which is initialized in `awt_Pen.cpp`.

The `GDIHashtable` constructor calls `manager.add(this)`.

For this to work, the manager must have been initialized prior to the AwtPen. However, the order of which static initializers are run between different compilation units are not well-defined, and we've just been lucky so far that it works.

This problem is known as the "Static Initialization Order Fiasco", see e.g. https://en.cppreference.com/w/cpp/language/siof

I have solved this by encapsulating the static manager instance in a method, which guarantees that it has been initialized before use. This seemed to me to be the cleanest solution.

-------------

Commit messages:
 - 8346195: Fix static initialization problem in GDIHashtable

Changes: https://git.openjdk.org/jdk/pull/22736/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346195
  Stats: 14 lines in 2 files changed: 3 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22736/head:pull/22736

PR: https://git.openjdk.org/jdk/pull/22736