Update recommended configuration for GPG signing

[wetneb]

This attempts to document the new recommended configuration to sign artifacts with the maven-gpg-plugin as part of the deploy process.

It imitates this PR from the maintainer of the maven-gpg-plugin: https://github.com/xerial/sqlite-jdbc/pull/1082/files

Notes that this requires the maven-gpg-plugin version 3.2.0 or above, not sure if this is worth adding to the documentation as I expect this guide will mostly be followed by people setting up a new project (hopefully using the latest version of the plugin by default).

@cstamas I hope I got it right, feel free to suggest any improvements

Related issue: might be related to #600?

see also https://issues.apache.org/jira/browse/MGPG-90?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=17825880

Check list:

• [x] Mark if documentation changes are required.
• [ ] Mark if tests were added or updated to cover the changes.

[wetneb]

With the release of the 3.2.1 version of the maven-gpg-plugin, this documentation update is less important as 3.2.1 will continue to work like the previous versions.

However, on the long term, this would likely still be a better choice than the current set up, as it removes the dependency on an external GPG agent. Arguably setup-java shouldn't have anything to do with setting up a GPG environment as it's unrelated to Java.

One downside of this method is the additional -Dgpg.signer=bc that needs to be added to mvn package. Perhaps that's something that could be removed in the future, if the maven-gpg-plugin is able to detect by itself that it is running in an environment where GPG hasn't been set up at all.

[cstamas]

Note: 3.2.1 is out, that restores "old way" working.

Still, I'd emphasize that with 3.2.x plugins, the "preferred" way of signing on CI like environments is using BC and passing secrets (key and passphrase) as environment variables. No more hoops and loops, like installing key into GnuPG and getting passphrase via crafted settings.xml should be needed. Ideally, no secret should get onto any disk/persistent storage.