Consistent use of arity annotation in CLI options: RPC, P2P

[macfarla]

PR description

Introduce consistency of PicoCLI annotations. Inspired by this PR attempting to make sense of booleans in the besu docs: hyperledger/besu-docs#1890

PicoCLI default arity info https://picocli.info/#_default_arity
for booleans, default arity is 0..1
for everything else, default arity is 1 - so you only need to specify arity if it is != 1

So this PR

• removes arity = 1 from non-boolean options
• removes arity = 1 from boolean options and ensures they have a semantically sensible fallback value
  • I started doing this but it would be a breaking change, since it would no longer allow for example --p2p-enabled true but instead would require --p2p-enabled=true so reverted those changes.

Note this PR does not address all instances of this, but if there is agreement on this approach we can roll it out across all options classes.

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
• hive tests: Engine or other RPCs modified?

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[fab-10]

LGTM, a nice addition is to have a error prone check to enforce this.

I agree with keeping the 0..1 for boolean, because otherwise it will break too many existing deployment.