Add support for dynamic linking of JDK libraries on Windows

[pejovica]

The main problem is that libraries such as awt.dll have load-time dependencies on jvm.dll and libraries that may already be statically linked, such as java.dll. So for dynamic linking to work, we need to:

1. Identify all used JDK libraries and copy them next to the native image.
2. Create shim DLLs, as a replacement for problematic dependencies, that will redirect exported calls back to the native image itself.

[kkriske]

1. Identify all used JDK libraries and copy them next to the native image.

awt.dll requires:

• jvm.dll
• java.dll

java.dll requires:

• jvm.dll
• verify.dll

verify.dll requires:

• jvm.dll

jvm.dll has no (java) dll requirements.

Our current setup has jvm.dll, verify.dll, java.dll and awt.dll in a /lib subfolder next to the native-image and hardcoded references in System#load calls, loading them in that order, which works as a charm.

Do note, that we also set java.library.path to include that /lib folder. Which, looking at the code, would for now still be a requirement as this ensures that the dll found by the normal System.loadLibrary("awt") calls throughout the code, also find the already loaded dll from the lib folder.

This is obviously specifically for #3084

[kirillp]

Support for dynamic linking of JDK libraries (which is actually Graal-runtime in this case, since we don't need hot-spot compilers or various gc) on any system would be good.
Linking into executable, however, allows some benefits like striping dead code
So both options is nice to have.