Run on JPA 3.2 and 4, from a single artifact.

[oscarfanchin]

Handling interoperability between generations turned into two distinct problems.

Hibernate's changes to SPIs and classes are handled by two reflective adapters, one per Hibernate
generation. The binary incompatibility between the Jakarta Persistence 3.2 and 4.0 signatures is
handled by a bridge. On 3.2, which is the baseline, the calls go through directly; on 4.0 they rely
on reflection.

Hibernate 8.x is used through opt-in profiles and the snapshot repository is declared inside them,
so the default build resolves nothing from it.

I tried to make the way I worked visible in the commits: cross-version compilation first, then the
build and the tests obtained by recompiling, with the behaviour changes documented as they came up.

The point is where this ends up: a build made only against Jakarta Persistence 3.2 and Hibernate 7
runs under both profiles, without recompiling.

Three of these changes are deliberately standalone, so any one of them can be dropped without
affecting the others: the temporary artifact versions, the AOT generation change, and the workaround
for Hibernate 8 named queries. I tried it, and they come out easily.

Rationale in #4197.

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[oscarfanchin]

Hi @mp911de

Rebased after the 4.2.0-M1 release. The branch now builds against Hibernate 7.4.5 and EclipseLink 5.0.1, and the suites are green on the default profile and on the Hibernate 8 ones.

One commit dropped in the rebase: the EclipseLink test filtering is already handled on main.