[JEXL-446] Accept module packages with qualified exports

[wrprice]

ClassTool.isExported(Class) attempts to check, on Java 9+, whether the package
containing the class is exported per the Java Module System. A package must at
least be exported in order for its public members to be read via reflection by
another module. It uses reflection to access the Java 9+ APIs so that JEXL can
still run on Java 8, and the check is bypassed in this case.

The issue was the use of Module.isExported(String), which accepts only a package
name. This method is defined to return true if and only if the named package is
unconditionally exported, i.e. to any module that wants to read it. But Java also
supports qualified exports, where a module can export a package only to one
or more specifically named other modules; this is a mechanism for least-privilege
access. For example:

module org.example.module {
  exports org.example.module.api; // unqualified or unconditional
  exports org.example.module.scripting to org.apache.commons.jexl3; // qualified
}

JEXL 3.5.0 would accept classes from the o.e.m.api package in the above example, but
reject classes in o.e.m.scripting even though Java would permit access to the JEXL module.

The fix is to use a different overload: Module.isExported(String, Module) passing JEXL's
own module as the 2nd method parameter. This continues to return true for the unqualified
or unconditional exports, but now also returns true for the qualified form as well.

Thanks for your contribution to Apache Commons! Your help is appreciated!

Before you push a pull request, review this list:

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request.
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best-practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[henrib]

Nice one, thanks. 👍