Remove ph-security runtime dependency on ph-bc

[gregjotau]

What this changes

• Replaces the Bouncy Castle CRL Distribution Points parsing in CRLHelper with a small, strict DER parser for the exact X.509 extension subset used there.
• Uses the RFC-defined OCSP response status values directly instead of importing Bouncy Castle constants.
• Moves ph-bc to test scope in ph-security; existing certificate-generation tests can keep using it.
• Preserves the existing public API, returned CRL URLs, logging, CRL prefetch/cache behavior, and revocation-check implementation.

Why

Downstream Peppol/phase4 applications otherwise receive the complete Bouncy Castle stack solely because ph-security has two small ASN.1/constant linkages. Modern JDK APIs cover the certificate, trust, and revocation operations, but do not expose a supported public CRL Distribution Points decoder. The included parser is deliberately limited to the relevant DER structure rather than introducing another general ASN.1 dependency or using internal JDK classes.

This does not remove the ph-bc module or prevent applications from choosing the BC provider. It only makes standard ph-security X.509 use provider-neutral.

Verification

• mvn -pl ph-security -am verify — all 15 reactor modules passed.
• Full ph-security suite — 80 tests, 0 failures/errors (2 existing skips).
• Existing real Peppol certificate CRL test still returns the same URL.
• Added coverage for multiple distribution points/general names and malformed/truncated DER.
• Added an isolated classloader regression test using real Peppol PKCS#12/JKS material while deliberately hiding both org.bouncycastle.* and com.helger.bc.*.
• Runtime dependency-tree filter for BC/ph-bc is empty.
• Compiled ph-security production classes contain no org/bouncycastle or com/helger/bc references.
• Forbidden API checks pass; no internal JDK APIs are used.

A small follow-up in peppol-commons can remove its direct ph-bc dependency once this is available in a ph-commons release.

[gregjotau]

Additional downstream verification is complete against the local snapshot chain from this PR, phax/peppol-commons#81, and phax/phase4#395:

• forced ph-security:12.3.6-SNAPSHOT, peppol-commons:12.8.2-SNAPSHOT, and phase4-lib:4.6.2-SNAPSHOT into our Gradle/Spring Peppol AP;
• dependencyInsight on the complete web-app runtime classpath reports no matches for org.bouncycastle, org.cryptacular, or com.helger.commons:ph-bc;
• the full clean :web-app:build passed (504 tasks);
• the application started with the provider-free graph and returned its expected login redirect over HTTP.

So the proposed sequence has now been exercised through a real downstream application, not only the individual Maven modules.