Support compatibility with JPMS

JPMS introduced the concept of the module path in addition to the classpath but the spec currently strongly requires usage on the classpath in a way disallowing users to pass their entities (etc) through the module path. For example, in [section 8.2.1.6](https://jakarta.ee/specifications/persistence/3.1/jakarta-persistence-spec-3.1#a12305), there we have:

_The classes and/or jars that are named as part of a persistence unit must be on the classpath_ and _All classes must be on the classpath to ensure..._.

While obvious and trivial solution to this is to add _or on the module path_, I do not think it is the right way to approach this.

Another thing to consider is to how to allow and define dealing with reflective access required by persistence providers. My way of thinking here is that as a user, I want to define my JPMS descriptor following way:

```
module org.my {
requires jakarta.persistence;
opens org.my.entities to jakarta.persistence;
}
```

and let the ~~runtime~~ API to find the right provider and pass the _open_ declaration to him - something similar to what [XML Binding](https://jakarta.ee/specifications/xml-binding/4.0/jakarta-xml-binding-spec-4.0#jaxbcontext) has:
_If JAXB-annotated classes or packages referenced in context path are defined in a Java Platform Module System (JSR 376) module, they must be open (as specified in javadoc of java.lang.Module#isOpen()) to at least jakarta.xml.bind module._

Start with Jakarta Persistence specification section 8.2.1.6 and the JPMS module descriptor example in the issue. Define what module-path support and reflective access requirements should mean for persistence providers, then update the specification once the behavior and completion criteria are agreed.

Written by the indexing model from the issue text.