Agnostic_baker: Rework help and version commands and refactor

What

Parent MR: !17050 (merged)

Closes #7852 (closed).

Also, it gets rid of the annoying -- needed to run the agnostic baker binary (which was a notable difference between the agnostic baker and the "classical" baker). Now, we can truly tell the users that they can just swap the old baker with the agnostic baker without any difference in CLI syntax 😄

Why

Because the UX was quite bad in my opinion. As you can see from the results, after this MR the situation clearly improves.

How

As suggested in the issue:

• when we get a --help, --version or man, we simply call the Client_main_run.run function without other arguments, as the run function will solve the request from the user
• otherwise, nothing changes, we run the agnostic baker as we did before

Manually testing the MR

Before:

./octez-experimental-agnostic-baker --help

returned

Cannot run agnostic baker without any baker arguments. Please refer to the following help:
Usage:
  octez-experimental-agnostic-baker [OCTEZ-EXPERIMENTAL-AGNOSTIC-BAKER-COMMANDS] -- [OCTEZ-BAKER-COMMANDS]

OCTEZ-EXPERIMENTAL-AGNOSTIC-BAKER-COMMANDS:
  --help: display help

OCTEZ-BAKER-COMMANDS:
 Run ./octez-baker-<PROTOCOL_HASH> --help

After:

Usage:
  octez-experimental-agnostic-baker [global options] command [command options]
  octez-experimental-agnostic-baker --help (for global options)
  octez-experimental-agnostic-baker [global options] command --help (for command options)
  octez-experimental-agnostic-baker --version (for version information)

To browse the documentation:
  octez-experimental-agnostic-baker [global options] man (for a list of commands)
  octez-experimental-agnostic-baker [global options] man -v 3 (for the full manual)

Global options (must come before the command):
  -d --base-dir <path>: client data directory (absent: TEZOS_CLIENT_DIR env)
  -n --no-base-dir-warnings: silence warnings about client data directory
  -c --config-file <path>: configuration file
  -t --timings: show RPC request times
  --chain <hash|tag>: chain on which to apply contextual commands (commands dependent on the context
    associated with the specified chain). Possible tags are 'main' and 'test'.
  -b --block <hash|level|tag>: block on which to apply contextual commands (commands dependent on the context
    associated with the specified block). Possible tags include 'head' and 'genesis' +/- an optional offset
    (e.g. "octez-client -b head-1 get timestamp"). Note that block queried must exist in node's
    storage.
  -w --wait <none|<int>>: how many confirmation blocks are needed before an operation is considered included
  -p --protocol <hash>: use commands of a specific protocol
  -l --log-requests: log all requests to the node
  --better-errors: Error reporting is more detailed. Can be used if a call to an RPC fails or if you don't
    know the input accepted by the RPC. It may happen that the RPC calls take more time however.
  -A --addr <IP addr|host>: [DEPRECATED: use --endpoint instead] IP address of the node
  -P --port <number>: [DEPRECATED: use --endpoint instead] RPC port of the node
  -S --tls: [DEPRECATED: use --endpoint instead] use TLS to connect to node.
  -m --media-type <json, binary, any or default>: Sets the "media-type" value for the "accept" header for RPC
    requests to the node. The media accept header indicates to the node which format of data serialisation is
    supported. Use the value "json" for serialisation to the JSON format.
  -E --endpoint <uri>: HTTP(S) endpoint of the node RPC interface; e.g. 'http://localhost:8732'
  -s --sources <path>: path to JSON file containing sources for --mode light. Example file content:
    {"min_agreement": 1.0, "uris": ["http://localhost:8732", "https://localhost:8733"]}
  -R --remote-signer <uri>: URI of the remote signer
  -f --password-filename <filename>: path to the password filename
  -M --mode <client|light|mockup|proxy>: how to interact with the node
  --log-coloring <true|false>: Enable or disable light coloring in default stdout logs. Coloring is enabled
    by default.

Also, when running the agnostic baker, we do no longer need to put the --:

./octez-experimental-agnostic-baker --base-dir ~/.tezos-client-ghostnet --endpoint http://localhost:18733 run with local node ~/.tezos-node-ghostnet --liquidity-baking-toggle-vote pass --without-dal

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR