Make Bouncy Castle optional in phase4-lib

[araiprof]

Summary

This follows the dependency cleanup in #340 by removing the remaining eager Bouncy Castle requirement from the phase4 core path.

• store the seven standard content-encryption OIDs as dot-decimal strings instead of eagerly reading CMSAlgorithm constants
• add the provider-neutral getOIDString API
• retain and deprecate getOID, constructing its ASN1ObjectIdentifier lazily for source and binary compatibility
• mark ph-bc optional in phase4-lib
• declare ph-bc locally in the BDEW production module and in modules whose tests directly use BC

Normal AS4 use and direct calls to ECryptoAlgorithmCrypt.getOIDString can now run without BC. This does not remove BC from the BDEW profile, which directly uses BC APIs.

Compatibility note

The deprecated getOID method keeps its ASN1ObjectIdentifier return descriptor for binary compatibility. Calling it still requires ph-bc. Reflection or AOT tools that eagerly resolve every method descriptor also still require ph-bc until that legacy method can be removed in a future major release.

Verification

• isolated classloader test initializes every ECryptoAlgorithmCrypt value and reads every OID with all org.bouncycastle classes hidden
• separate Java 26 Maven consumer compiled and ran with ph-bc and Cryptacular excluded and no Bouncy Castle artifacts present
• seven-module reactor verify: 204 tests, 0 failures/errors, 1 existing skip

This PR changes only the direct phase4/ph-bc edge; the independent WSS4J/Cryptacular path is intentionally unchanged.

[phax]

Please elaborate why this would be desirable. What alternative would you use instead?

[gregjotau]

@phax Thanks for asking for the rationale. I am the contributor behind this change, but I accidentally opened #386 from the wrong GitHub account. I have reopened it from my personal account as #389 with a fuller explanation of the dependency boundary and the exact alternative.

The short answer is: no replacement crypto provider is proposed. The seven values are stable standards-defined OIDs, so phase4-lib can retain them as canonical dot-decimal strings while actual AS4 signing/encryption continues through WSS4J/JCA. The BC-typed getOID method remains lazily available for compatibility, and modules with real BC usage retain explicit ph-bc dependencies.

Please treat #389 as the active PR and close/ignore this one. Sorry for the account confusion.

[phax]

Okay thanks - closing this one