Provide a separate annotation for registering classes for serialization

[zakkak]

Description

As discussed in #20167 (comment) the use of @RegisterForReflection(targets = String.class, serialization = true) is a bit confusing since it doesn't make clear whether the corresponding class should also be registered for reflection in general (right now it does not).

At the moment it's also not clear how to register a class for both reflection and serialization. Would

@RegisterForReflection(targets = String.class)
public class ReflectionConfig { }

@RegisterForReflection(targets = String.class, serialization = true)
public class SerializationConfig { }

do the trick in such cases?

As a result this feature request is about providing a cleaner interface (through a new annotation) to the end users for registering classes for reflection, serialization, or both.

Implementation ideas

As proposed by @vsevel it looks like a better approach would be to use a new annotation (instead of parameterizing RegisterForReflection).

Then to register a class for both reflection and serialization one should do the following:

@RegisterForReflection
@RegisterForSerialization
public class MyClass {
}

or

@RegisterForReflection(targets = String.class)
@RegisterForSerialization(targets = String.class)
public class ReflectionConfig { }

[Sanne]

Not sure if it should be a separate issue, but I'd also love it if we could tune the API of @RegisterForReflection to strongly encourage adding a conditional tied to code reachability - perhaps it should be a required attribute of the annotation?

I understand that making it required would make it a lot of work to migrate to the new annotation, but a good compromise would be to have a default conditional which signals "I haven't thought of this yet"; this could be a placeholder, and we could deprecate it already to discourage excessive use, especially discourage in new code.

[zakkak]

+1 that will also be in line with the new "Conditional Configuration" that is coming in GraalVM 21.3

I think, however, that this should be in a separate feature request :)

[Sanne]

Ok for a separate feature request: opened #20331

but if we change the API let's try to do it only once and address both aspects.