Add missing metadata for hibernate-core

[christophstrobl]

What does this PR do?

Add missing metadata for hibernate-core required to instantiate generator types retrieved from annotation attribute.
Closes: #323

Checklist before merging

• I have considered including reachability metadata directly in the library or the framework (see our contributing document)
• I am the original author of all content provided in the pull request, and I did not copy the content from any other source (see the tests section from our contributing document)
• For all tests where I am not the sole author, I have added a comment that proves I may publish them under the specified license (see the tests section from our contributing document)
• I have properly formatted metadata files (see our formatting guide)
• I have added thorough tests (see the tests section from our contributing document)
• I have filled all places where my pull request accesses files, network, docker, or any other external service (see the section above)

[sdeleuze]

I think this kind of hints should be determine dynamically on Framework side and not contributed in a static way here. I implemented that on Spring Framework via spring-projects/spring-framework#32842 and spring-projects/spring-framework#32967, so I propose to decline this PR and close it unmerged.

@christophstrobl Ok for you?

[christophstrobl]

@sdeleuze framework support for this kind of stuff is very nice but will not work for those not relying on them. Since they are hibernate core types I'd rather see them present here.

[sdeleuze]

@melix Any thoughts?

[melix]

@msupic @dstepanov is this needed for Micronaut?

[dstepanov]

It would be nice to have it. I don't know what the reasoning is for having it determined dynamically.

It might be a good idea for the native config to provide a list of interfaces/abstract classes meant to be instantiated by the reflection. Any implementation class would be automatically added, and all the constructors would be open for reflection.

[sdeleuze]

The reason for implementing a dynamic discovery is to handle custom implementation specified via annotation, but this PR provide default ones which does not hurt with Spring feature, so let's maybe merge it to provide support for the most common use cases with all frameworks.