[GR-69577] Make --future-defaults=complete-reflection-types default

[graalvmbot]

This makes the reflection registration code unconditionally consider types registered through the "name" property of reflect-config.json in the same way as those registered through the "type" property of reachability-metadata.json, which enables a big reduction in the complexity of that code, which will be tackled as part of GR-67330. Reflective access registration will now only need to be specified in terms of classes, methods and fields, removing the need for fine-grained registration methods such as RuntimeReflection.registerAsQueried(Executable) or RuntimeReflection.registerNestMembers(Class).

This update required several fixes to adapt some parts of the codebase to handle queried-only methods, which are now more prevalent. These fixes are split into separate commits to facilitate reviewing.

Metadata changes

Without this future default, users are able to create reflect-config.json like the following:

[
    {
        "name": "registered.ReflectionType",
        "queryAllDeclaredMethods": true,
        "queryAllPublicMethods": true,
        "queryAllDeclaredConstructors": true,
        "queryAllPublicConstructors": true,
        "allDeclaredClasses": true,
        "allPublicClasses": true,
        "allNestMembers": true,
        "allPermittedSubclasses": true,
        "allRecordComponents": true,
        "allSigners": true
    }
]

This file is strictly equivalent to the following reachability-metadata.json file using our latest metadata format:

{
    "reflection": [
        {
            "type": "registered.ReflectionType"
        }
    ]
}

The future default --complete-reflection-types makes the following reflect-config.json file behave the same way as the two files above:

[
    {
        "name": "registered.ReflectionType",
    }
]

This effectively deprecates all the extra fields present in the first reflect-config.json file, and allows a great simplification of the internal reflection logic since these fields can't be set individually anymore.

Backwards compatibility

These changes cause a strict increase of reflection registrations. Users may see a small increase in image size, which has been documented in #7753 and deemed acceptable.

Existing code will not see reflective queries fail where they previously succeeded. However, there is one scenario which may cause failures. Code using the following pattern:

for (Method method : clazz.getMethods()) {
    if (condition) {
        method.invoke(receiver, args);
    }
}

may rely on the fact that getMethods() currently only returns the subset of methods that have been registered for reflection when clazz was registered through "name" in reflect-config.json. One of the consequences of this PR is that getMethods() will now either fail (when the class is not registered) or return the complete list of public methods for the class, some of which might satisfy the condition and be invoked, triggering a MissingReflectionRegistrationError as they have not been registered for reflective invocation.

It is important to note here that this invocation is the expected behavior of the program, which was excluded by the user through incomplete reflection registration. This code pattern, where users rely on Native Image deviating from the standard Java behavior, is one of the primary reasons that led to the introduction of complete reflection types. It is therefore expected that users will have to adapt in this case. The fix for this type of issue is very simple: the user only has to add the missing method (or field, as getFields() can be used in the same way) to the reachability metadata, which is made trivially easy by the new missing registration error messages introduced recently.