[GR-59780] [GR-53985] Add ForNameRespectsClassLoader and integrate Crema in the class loading path.

[graalvmbot]

• Introduce the experimental ForNameRespectsClassLoader option and use it in Crema:
  • Add class registries for class loaders, add classes at build time based on their defining class loader.
    • In crema mode add all classes.
    • Without crema, only classes that are configured for runtime reflection are added.
  • Those registries are used to serve Class.forName, ClassLoader.loadClass, and ClassLoader.findClass queries.
  • Use as much as possible of the standard class loading code from the JDK as possible. In particular let the class loader delegate to each other.
  • Even without crema, classes might be added to the registries as those represent the set of classes for which a class loader was an "initiating class loader".
  • Add class loading scopes experimental API to allow ignoring the reflection configuration in explicit scopes.
  • In the crema case, wire class definition (ClassLoader.defineClass) to the shared class file parser.
• Move espresso shared code to a separate suite and apply CPE
• Shade espresso shared code for usage in svm to avoid conflicts with espresso shared code used in application code (e.g., espresso native images)
• Avoid usage of TruffleLogger in espresso.classfile
• Add hellocrema command to exercise class loading
• Rename SupportRuntimeClassLoading option to RuntimeClassLoading
• Minor javadoc fix

Some things are left out in this PR and will need to be addressed / done separately:

• Proper package mapping for module support (package -> module maps in class loaders as defined by Module.defineModule0) GR-62339
• Layer support for the ClassRegistryFeature
• Parallel class loading support GR-62338
• JVMS Loading constraints GR-62320