[GR-49523] Minimize Build-Time Initialization of the JDK

[vjovanov]

TL;DR

Native Image currently initializes large portions of the JDK at build time. This is problematic for the following reasons:

1. It requires many substitutions that are hard to maintain and that introduce subtle bugs to the JDK.
2. It requires additional configuration from the users even if they do not use initialization at build time themselves: The JDK can initialize user classes at build time and store them in the image heap.
3. In some cases where illegal user types are stored in the heap, it is impossible to compile programs with Native Image.

We plan to reduce initialization at the build time of the JDK classes only to classes that are necessary for the implementation of the Native Image runtime. We do this as initialization at build time for the JDK is not necessary due to the new class-initialization policy introduced in GraalVM for Java 21 (--strict-image-heap). If benchmarks show that some classes need to be initialized at build time for performance reasons (e.g., Java collections), we will add those classes to the set of build-time initialized classes.

Goals

1. Remove the need for any build-time initialization by the users of the JDK.
2. Prevent bugs that are coming from the build-time initialization of the JDK.

Non-Goals

1. Make programs slower.
2. Make the image size bigger.
3. Make project configuration harder.

Backwards Compatibility

This feature can break existing code that uses build-time initialization: If one of the classes that were initialized by the JDK is stored to the image heap in user code, the builds will require additional configuration.
This feature will be rolled out over 4 releases. Each bullet represents one release of GraalVM:

1. The experimental release where this feature is behind an experimental flag that can be used by the framework authors to adjust all the config.
2. The preview release where this feature is behind an API flag that is suggested to the users in the build output.
3. The release where the new flag is the default and users can revert to the previous behavior by using a deprecated non-API flag.
4. The release where the deprecated flag is deleted.