[GR-68047] Split up and rename future defaults.

[graalvmbot]

This allows gradual evolution of community code as well as separate promotion of individual options to default.

The reason is that we will not be able to promote our code gradually to future defaults. Say we want to move security providers to run time by default in 26 and say the library code does the following:

if (!Boolean.parseBoolean(System.getProperty("org.graalvm.nativeimage.future-defaults.run-time-initialize-jdk"))) {
    RuntimeClassInitialization.initializeAtBuildTime("...");
    ...
}

Now when we promote the security providers to default, all of the users that don't use --future-defaults will get the code above executed which is not correct anymore.

By having fine-grained properties we avoid that because the property will be set to "true" indefinitely and the code snippet above will take the right turn for all future versions.