Prepare SBOM integration for GraalVM 25

[rudsberg]

This PR updates the SBOM integration in the native-maven-plugin to handle SBOMs being embedded by default in GraalVM 25. SBOMs will be embedded even if --enable-sbom is not passed to native-image. We have updated our checks accordingly to ensure the base SBOM is generated only when the SBOM feature is enabled.

Additionally, the option augmentedSBOM has been renamed to skipBaseSBOM. We are discontinuing the use of the term "augmented" and will instead refer to the SBOM produced by native-maven-plugin (and consumed by native-image) as the "base" SBOM. The new "skip" prefix aligns better with other configuration options. skipBaseSBOM defaults to false and when set to true the base SBOM is not generated.

With regards to backwards compatibility, I believe the deprecation of augmentedSBOM should be OK given that it was just recently introduced for 24 and it's not documented in the public native-maven-plugin documentation.

[rudsberg]

The failing functional tests seems unrelated to this PR, but I'm looking into it.

The failing test is JavaApplicationFunctionalTest > can build and execute a native image with the Maven plugin when the application has a custom packaging type FAILED and fails with:

org.graalvm.demo.ApplicationTest > message is hello native FAILED
Failures (1):
JUnit Jupiter:ApplicationTest:message is hello native
MethodSource [className = 'org.graalvm.demo.ApplicationTest', methodName = 'usesReflection', methodParameterTypes = '']
=> org.opentest4j.AssertionFailedError: expected: <Hello, native!> but was: <null>

Update:
I've identified and resolved the issue. Here’s what went wrong:

• This PR correctly generates a base SBOM for GraalVM 25 builds that embed SBOMs by default. In other words, previously all functional tests running on GraalVM 25 and that did not use --enable-sbom did not exercise the SBOMGenerator code path, but now they do.
• That caused this line to fail. The reason was that it uses mvnDebug, causing excessive printing by the cyclonedx-maven-plugin on version 2.8.1 that we were using, leading to a java.lang.OutOfMemoryError.

The excessive printing seemed like a bug, so I tried updating cyclonedx-maven-plugin to the latest version (2.9.1), which indeed solved it. It now logs in a reasonable manner.

[rudsberg]

We now catch all exceptions to avoid the risk of a runtime exception bypassing this fallback mechanism.

[rudsberg]

The logging suppression was removed because it was not working. Setting the logging level like so doesn't restrict the logging in the executeMojo call. Another PR could ensure that the output from cyclonedx-maven-plugin is suppressed.

[rudsberg]

Minor orthogonal improvement.

(Shaded dependencies are correctly marked as non-prunable since we cannot be sure the packageNames are accurate. Therefore, leaving the packageNames array empty increases clarity.)