Add support for composite ids

[schauder]

Entities may be annotated with @Id and @Embedded, resulting in a composite id on the database side.
The full embedded entity is considered the id, and therefore the check for determining if an aggregate is considered a new aggregate requiring an insert or an existing one, asking for an update is based on that entity, not its elements.
Most use cases will require a custom BeforeConvertCallback to set the id for new aggregate.

For an entity with @Embedded id, the back reference used in tables for referenced entities consists of multiple columns, each named by a concatenation of + _ + .
E.g. the back reference to a Person entity, with a composite id with the properties firstName and lastName will consist of the two columns PERSON_FIRST_NAME and PERSON_LAST_NAME.
This holds for directly referenced entities as well as List, Set and Map.

Closes #574

[mp911de]

This is quite a PR with a lot of changes. I did a review pass on it capturing most impressions as comments. This PR introduces a lot of accidental complexity making the actual changes much more difficult to understand. I think rewriting some parts to simpler forms that make concepts more explicit (instead of implicit ifs or for-loops that do something) helps to understand the code.

Assertions that assert more than three items in a row exhaust my capability to understand these, also asserting tuples might technically work but that leads to test code that is much more difficult to understand than what is the actual functionality tested. If we continue that way, you'll be the sole person that is able to maintain the project.

I tried to make suggestions as concise as possible for improvements to reduce conceptual (and code) duplications.

[mp911de]

There's so much to read in these test style that the actual test fixture and test code becomes invisible.

Please use much simpler assertions, otherwise I don't understand what is happening here.

Applies also for many other places in this project.

[mp911de]

I wonder whether we could simplify our detection. If a simple type is annotated with @Id, we consider it a simple identifier. Any non-simple type annotated with @Id is automatically considered an embedded/composite Id without the need to use @Embedded. @Embedded raises the question of Embedded.onEmpty(). Being able to provide more detail via @Embedded is a nice detail.

It would be also neat to have Mapping Annotation Overview explaining that @Id can be simple or embedded/composite identifiers along with embedded Id examples. So far, @Id is only used with simple types in code samples.