WIP: CLI refactor

[renanrodrigo]

Why is this needed?

This PR solves all of our problems because this will set a new standard for the Pro Client CLI, which will be leveraged for the new UX implementation.

• Implement commands and arguments as classes
• Simplify separation of concerns, maintainability and testing
• Split the CLI into submodules
• Test help text in behave

Test Steps

~This PR should contain only refactors.~ Yep check tox and behave, small changes to help text

---

• [ ] (un)check this to re-run the checklist action

[github-actions[bot]]

PR Checklist

How to use this checklist

### How to use this checklist #### PR Author For each section, check a box when it is true. Uncheck a box if it becomes un-true. Then check the box at the bottom of the PR description to re-run the action that creates this checklist. The action that creates and updates this comment will retain your edits. The action will fail if the checklist is not completed. #### PR Reviewer Check that the PR checklist action did not fail. Double check that the author filled out the checklist accurately. If you disagree with a checklist item, start a conversation. For example, the author may say they don't think integration tests are necessary, but you may disagree.

### Bug References None. #### Confirm - [ ] I've properly referenced all bugs that this PR fixes

How to properly reference fixed bugs

* If this PR is related to a Jira item, include an `SC-1234` reference in the PR title * If this PR is fixes a GitHub issue, include a `Fixes: #1234` reference in the commit that fixes the issue * If this PR is fixes a Launchpad bug, include a `LP: #12345678` reference in the commit that fixes the issue

### Test Updates #### Unit Tests - [ ] I have updated or added any unit tests accordingly - [ ] No unit test changes are necessary for this change #### Integration Tests - [ ] I have updated or added any integration tests accordingly - [ ] No integration test changes are necessary for this change ### Documentation - [ ] Changes here need to be documented and I have referenced the docs PR in the description - [ ] No documentation updates are necessary for this change ### Does this PR require review from someone outside the core ubuntu-pro-client team? - [ ] Yes, and I have requested those reviews via GitHub - [ ] No

[renanrodrigo]

@lucasmoura @orndorffgrant @dheyay I want to do this to ALL commands but please take preliminary looks to make sure you agree with the structure - easier to change earlier when less commands are implemented/affected

[renanrodrigo]

@orndorffgrant I want to do this to all commands, yes - maybe incrementally, simple ones in this PR, if I find something more tricky (and I will) I can send it separate for ease of review. As it is a refactor anyway, we can merge without usability changes

[orndorffgrant]

@orndorffgrant I want to do this to all commands, yes - maybe incrementally, simple ones in this PR, if I find something more tricky (and I will) I can send it separate for ease of review. As it is a refactor anyway, we can merge without usability changes

@renanrodrigo makes sense. Maybe can you prioritize the subcommands that have their own module? The we'd only have "new" commands in this form and "old" commands in cli/__init__.py (and no "in-between" commands in the better-but-not-as-good separate module form)

[renanrodrigo]

@renanrodrigo makes sense. Maybe can you prioritize the subcommands that have their own module? The we'd only have "new" commands in this form and "old" commands in cli/__init__.py (and no "in-between" commands in the better-but-not-as-good separate module form)

Not sure - some of those have been separated exactly because they are more complicated somehow. I'll try and see what happens