##### SUMMARY

In #65933, I had some confusion over how to set my Galaxy token for CLI usage when running `ansible-galaxy collection publish`, so I could avoid setting `--api-key` on the command line.

Some of that confusion could be avoided by using the same terminology when referring to the Galaxy 'token' everywhere. Currently the docs pages for Galaxy and Collections both mention 'token' multiple times, and only mention the term 'api-key' once, in reference to the Galaxy CLI.

Complicating matters, if I log into galaxy.ansible.com and go to my Preferences, I am shown an "API Key" section. So... it is even less clear whether I should be using a token or API key in various places.

I think, in the end, they are the same thing. But it would be more clear if we just call it one thing everywhere. Therefore, I propose we deprecate the `--api-key` parameter in the `ansible-galaxy` CLI, and use `--token`.

(And we should also change the UI in Galaxy to read 'Token' instead of 'API Key', maybe?)

Alternatively, if 'API Key' is the chosen nomenclature, let's use that everywhere, and ditch the use of 'token'...?

##### ISSUE TYPE
- Feature Idea

##### COMPONENT NAME
galaxy

##### ADDITIONAL INFORMATION
See related: #65933
---
            roles:
            # Same as v1 format just under the roles key
            collections:
            - namespace.collection
            - name: namespace.collection
              version: version identifier, multiple identifiers are separated by ','
              source: the URL or a predefined source name that relates to C.GALAXY_SERVER_LIST
        :param requirements_file: The path to the requirements file.
        :param allow_old_format: Will fail if a v1 requirements file is found and this is set to False.
        :return: a dict containing roles and collections to found in the requirements file.
        """
        requirements = {
            'roles': [],
            'collections': [],
        }
        b_requirements_file = to_bytes(requirements_file, errors='surrogate_or_strict')
        if not os.path.exists(b_requirements_file):
            raise AnsibleError("The requirements file '%s' does not exist." % to_native(requirements_file))
        display.vvv("Reading requirement file at '%s'" % requirements_file)
        with open(b_requirements_file, 'rb') as req_obj:
            try:
                file_requirements = yaml.safe_load(req_obj)
            except YAMLError as err:
                raise AnsibleError(
                    "Failed to parse the requirements yml at '%s' with the following error:\n%s"
                    % (to_native(requirements_file), to_native(err)))
        if requirements_file is None:
            raise AnsibleError("No requirements found in file '%s'" % to_native(requirements_file))
        def parse_role_req(requirement):