Change Maven artifactIds to avoid possible collisions with other libs

[fab-10]

PR description

Currently Besu artifacts are published to Maven, with a groupId = org.hyperledger.besu[.internal] and the artifactId is just the name of the subproject, for example: p2p, core or plugin-api`.

That works fine for defining a dependency on any Besu lib using the Maven coordinates, since the couple: groupId + artifactId are unique, but there is a potential issue when packaging the project, since very generic artifactIds, like core, util and so on, could collide with other project dependencies using the same artifactId and the same calver, since the Maven repository layout states that the jar name is only the artifactId + version, so the groupId could not be used to disambiguate when collecting all the jars needed by the app, as the Gradle distribution plugin does for example.

The solution proposed in this PR, is to change the artifactId of Besu libs to be automatically set to the project path, that is the concatenation of all the project names from the root to the leaf.
This way: core becomes besu-ethereum-core or plugin-api become besu-plugin-api.
This is the approach taken by most common libs like: Vert.x, Netty, etc...

This is a breaking change, since Maven coordinates change and plugins will have to update their dependencies specification.

Known projects that are using Besu dependencies and need to be updated, where possible I will open a PR to update the coordinates and notify the team:

• Teku
• Web3j
• Hedera
• Paladin

Fixed Issue(s)

Thanks for sending a pull request! Have you done the following?

• Checked out our contribution guidelines?
• Considered documentation and added the doc-change-required label to this PR if updates are required.
• Considered the changelog and included an update if required.
• For database changes (e.g. KeyValueSegmentIdentifier) considered compatibility and performed forwards and backwards compatibility tests

Locally, you can run these tests to catch failures early:

• spotless: ./gradlew spotlessApply
• unit tests: ./gradlew build
• acceptance tests: ./gradlew acceptanceTest
• integration tests: ./gradlew integrationTest
• reference tests: ./gradlew ethereum:referenceTests:referenceTests

[garyschulte]

This LGTM - it will help with forks like op-besu as well.

It is probably worth checking to see what public projects might have dependencies on the current artifactId's. Cursory glance seems like at least a few web3j artifacts have dependencies, shomei, plugins, etc. Definitely worth a warning in the release notes.

[fab-10]

@garyschulte after some research I added to the description the list of known public projects that are using Besu dependencies, and will notify them about the change