Built-in support for translating more complex entity IDs (@EmbeddedId, @IdClass, ...) into document IDs

See also https://hibernate.atlassian.net/browse/HSEARCH-4352#icft=HSEARCH-4352

Currently, attempting to mark @Indexed an entity whose ID is derived from an association (see https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html#identifiers-composite-associations ) or whose ID is an @IdClass will result in an exception telling the user to define a @DocumentId. I believe an @EmbeddedId will result in a similar failure.

Maybe we should try to support those identifiers by default?

This would mean:

• Adapting the way of retrieving from an entity an object that represents the ID.

• Adapting the way we list all IDs of an entity when mass indexing; we can no longer assume the ID is a SingularAttribute.

• Automatic handling of the "composite-ness" of an ID by converting each component to a string, then concatenating it in a way that is both unique and lossless (so that we can convert the string back to the original components). We could get some inspiration from org.hibernate.search.backend.elasticsearch.multitenancy.impl.DiscriminatorMultiTenancyStrategy.DiscriminatorMultiTenancyElasticsearchDocumentIdHelper

• Handling IDs that contain entity references, which must be resolved from the session.

• ... more?