Fix BEASTClassLoader dual-loader class identity split

[alexeid]

Fixes #65.

Summary

• Add resolveLoaderFor(provider) to BEASTClassLoader: prefer the class-loader of the boot-layer module that owns the provider's package; fall back to the thread-context loader only when no named module claims the package.
• Use it from instance addServices(String, Map) and static addService(String, String, String) instead of unconditional fallbackClassLoader().

This brings the version.xml registration path in line with the JPMS provides registration path (mergeAllProviders / collectProviders), which already used m.getClassLoader() from the providing module.

Why

When beast-base is reachable via both the JPMS module path and the classpath in the same JVM (typical of surefire and IDE runs), the old code stored the app class-loader against every version.xml provider. BEASTClassLoader.forName() then returned the app-loader copy of (e.g.) beast.base.evolution.tree.Node, while application code resolved through the module-loader copy. The two Class<?> instances were incompatible, producing ClassCastException and an empty data-type registry. See #65 for the full diagnosis and reproduction.

Test plan

• mvn -pl beast-pkgmgmt test — 40/40 pass with the patch.
• End-to-end validation against LPhyBeast on a machine that previously hit the failures:

  cd ~/Git/beast3
  git fetch origin
  git checkout fix-classloader-dual-load
  mvn install -DskipTests

  Then in LPhyBeast/pom.xml change <beast.version>2.8.0-beta4</beast.version> to <beast.version>2.8.0-SNAPSHOT</beast.version> and run mvn -pl lphybeast test. The previously-failing H5N1TutorialTest.testDPG and the two LPhyScriptsToBEASTTest cases should pass.