Revise `PersistenceUnitInfo` management for compatibility with JPA 3.2 as well as JPA 4.0

[jhoeller]

Following up on #33750 and #33414, there is a remaining problem with the PersistenceUnitInfo#getTransactionType() in JPA 3.2 where the jakarta.persistence.spi.PersistenceUnitTransactionType enum is deprecated for removal - and the latest state of JPA 4.0 already has it replaced with jakarta.persistence.PersistenceUnitTransactionType. Anticipating that binary-incompatible breakage in the JPA SPI and taking into account that the new jakarta.persistence.PersistenceUnitTransactionType enum is available in JPA 3.2 (just not used in the JPA SPI yet), we can revise our PersistenceUnitInfo management toward decoupling it from the JPA PersistenceUnitInfo interface itself:

• Internally in DefaultPersistenceUnitManager, we hang on to SpringPersistenceUnitInfo which does not implement PersistenceUnitInfo directly anymore, then turning into an actual JPA PersistenceUnitInfo proxy (automatically adapting to JPA 3.2 vs 4.0) when requested from the PersistenceUnitManager.
• MutablePersistenceUnitInfo as exposed to PersistenceUnitPostProcessor provides the same common accessors and mutators as before. It just does not directly implement PersistenceUnitInfo anymore (aligned with SpringPersistenceUnitInfo which it serves as a base class for), so it cannot be passed into PersistenceUnitInfo-accepting methods anymore (which was never an intended scenario there anyway).
• MutablePersistenceUnitInfo consistently exposes the non-deprecated jakarta.persistence.PersistenceUnitTransactionType in its set/getTransactionType methods now, which prevents awkward "deprecated for removal" warnings on JPA 3.2 for anyone calling those methods.
• As a desirable side effect, persistence unit mutation only works during the bootstrap phase now. PersistenceUnitInfo handles obtained via EntityManagerFactoryInfo at runtime can only be downcast to SmartPersistenceUnitInfo but not to MutablePersistenceUnitInfo anymore, preventing late mutation that would not get picked up by the persistence provider.
• As a side note, it is not entirely new to receive a PersistenceUnitInfo proxy from Spring: We had this before for JPA 1.0 vs 2.0 side-by-side support where a proxy was returned in case of JPA 2.0 (also preventing runtime downcasts to MutablePersistenceUnitInfo back then).