Extract Java API from classfiles behind IncOptions.classfileJavaApi (#837)

[jozanek]

Builds on #1714 and #1729 (both merged). Completes the classfile-based Java API path so analysis can avoid reflective class loading entirely — the root cause of #837 / #151 / #1697 — behind a new opt-in IncOptions.classfileJavaApi (off by default).

• JVMS generic-Signature parser → real xsbti.api types (generics, bounds, wildcards); annotation element values, enum children, varargs, ctor Empty return.
• Inherited public members (incl. nested classes) recovered by reading parent classfiles as bytes — no class loading; matches reflection's structure (incl. its non-generic-supertype rule for inherited member classes).
• IncOptions.classfileJavaApi routes all Java classes through the classfile path (per-invocation option, parallel-safe, settable via incOptions.properties); local/anonymous classes mapped via the EnclosingMethod attribute.

Validated by a differential audit asserting structural parity with the reflection path (ClassToAPI) — member set, kind, access, arity, varargs, type-params, declared + inherited nested classes — plus an end-to-end incremental test (same recompiled set with the option on). Whole-class hashes intentionally differ (accepted one-time re-hash); flipping the default is a separate maintainer decision.

[eed3si9n]

Thanks for the contribution.

flipping the default is a separate maintainer decision.

If we want to backport this to 2.0.x, probably keep it as opt-in. For 2.1.x, we can make it on by default assuming it goes through its own RC cycle.

[jozanek]

Sounds good. It's opt-in here (classfileJavaApi defaults to false), so it's safe to backport to 2.0.x as-is. Happy to follow up with a separate PR flipping the default on for 2.1.x once this lands and can go through its own RC.