build(pom): move GPG signing to release profile

[marevol]

Summary

Stop requiring GPG signing for local builds by moving the maven-gpg-plugin into a `release` profile, matching the convention used by other CodeLibs repositories (corelib, curl4j, jcifs, etc.).

Changes Made

• Moved `maven-gpg-plugin` from the main `` section into a new `release` profile (same plugin definition: `sign` bound to the `verify` phase with `bestPractices=true`).
• Added `release` to `maven-release-plugin` so the profile is activated automatically during `release:perform`. This is needed because this repository releases via maven-release-plugin, unlike the other repos where `-P release` is passed manually.

Testing

• `mvn clean install -DskipTests` (no gpg flags): succeeds without invoking GPG.
• `mvn verify -P release`: confirms `gpg:sign (sign-artifacts)` is bound and executes under the profile.

Breaking Changes

• None for consumers. Release operators: signing now only runs under the `release` profile, which `release:perform` activates via `releaseProfiles`; manual deploys must pass `-P release`.

Additional Notes

• Previously, plain `mvn install` failed in non-interactive environments with `gpg: signing failed: Inappropriate ioctl for device` because signing was bound unconditionally.

[marevol]

Superseded by #28 — closing as redundant.

While this PR was open, #28 ("move source/javadoc plugins to release profile") moved maven-gpg-plugin into the release profile as well, using the identical plugin block and the same <releaseProfiles>release</releaseProfiles> on maven-release-plugin that this PR proposed. #29 then pinned maven-source-plugin to 3.2.1.

As a result, main already achieves this PR's goal (GPG signing now lives in the release profile, matching the corelib/curl4j/jcifs convention). Rebasing this branch onto current main resolves to a pom.xml identical to main and the commit collapses to an empty diff, so there is nothing left to merge.