Summary
-------

Add a JVM option: `-XX:+AOTClassLinking` to control the new behavior introduced in JEP 483

Problem
-------

JEP 483 allows classes in an AOT cache (historically known as a "CDS archive") to

- be bulk-loaded during JVM start-up
- have some of their symbolic references to other classes to be resolved ahead of time and replaced with direct pointer references

The new behavior of JEP 483 changes the order of when classes are loaded. This may affect some applications that rely on a specific order of class loading. E.g., some applications may assume that when class A is executed, class B is not yet loaded, so class A may attempt to dynamically define a different version of B. If both classes A and B are loaded immediately at JVM start-up, the dynamical definition of B would fail with a `LinkageError`.


Solution
--------

Although the Java specification does not guarantee the order of class loading, to ensure backwards compatibility with such applications, we use the `AOTClassLinking` flag to control whether the JEP 483 behavior is enabled.

Specification
-------------

An option `AOTClassLinking` of the `bool` type is added to the list of HotSpot JVM options.

- When an AOT cache is created with the new `-XX:AOTMode=create` flag, we assume that the application is aware of AOT class linking and does not depend of the class loading order. In this case, `AOTClassLinking` has a default value of `true`. The user can disable it by explicitly passing `-XX:-AOTClassLinking` in the JVM command line.

- When an AOT cache is created with existing "CDS" flags (`-Xshare:dump`, `-XX:ArchiveClassesAtExit`, `-XX:+AutoCreateSharedArchive`), as well as existing `jcmd VM.cds` commands, we assume that the the application may not be aware of AOT class linking. Therefore, `AOTClassLinking` has a default value of `false`.  The user can enable it by explicitly passing `-XX:+AOTClassLinking` in the JVM command line to indicate that the application makes no assumptions about class loader order.