Cleanup `hostmgr` various setup root commands

The `hostmgr` command has some lesser-used and setup-related subcommands that are a bit all over the place:

## Inconsistencies and spread out commands

- [`hostmgr set` and its sole `hostmgr set automatic-login-password` subcommand](https://github.com/Automattic/hostmgr/blob/018e7758a0a456d05656efb34425575b35c0ea58/Sources/hostmgr/HostMgrCommand.swift#L35-L43)
- [`hostmgr install` and its sole `hostmgr install hostmgr-helper` subcommand](https://github.com/Automattic/hostmgr/blob/018e7758a0a456d05656efb34425575b35c0ea58/Sources/hostmgr/HostMgrCommand.swift#L45-L53)
- [`hostmgr init`](https://github.com/Automattic/hostmgr/blob/018e7758a0a456d05656efb34425575b35c0ea58/Sources/hostmgr/HostMgrCommand.swift#L55-L65), which doesn't even really do what it claims (it creates the directories where the config file should be, but doesn't create a template config file like the command description suggests), and is separate from `hostmgr config` (which prints the current configuration)
- [`hostmgr sync` and its sole `hostmgr sync authorized-keys` subcommand](https://github.com/Automattic/hostmgr/blob/018e7758a0a456d05656efb34425575b35c0ea58/Sources/hostmgr/SyncCommand.swift#L5-L13)

Besides, there are some other inconsistencies:
- The struct implementing the `hostmgr generate` command, and implemented in `GenerateCommand.swift`, is still named `struct RunCommand` instead of `struct GenerateCommand`

## Proposed Solutions

The idea would be to move all the above commands as subcommands of a single root command, instead of having them spread out each as their own command with a single subcommand.

### Proposal 1️⃣ : Move everything under `hostmgr config`

| Old | New |
|---|---|
| `hostmgr set automatic-login-password` | `hostmgr config set-automatic-login-password` |
| `hostmgr install hostmgr-helper` | `hostmgr config install-helper` |
| `hostmgr init` | `hostmgr config init` |
| `hostmgr config` | `hostmgr config show` |
| `hostmgr sync authorized-keys` | `hostmgr config sync-authorized-keys`

The only thing that could feel odd with this is that `set-automatic-login-password` / `install-helper` and `sync-authorized-keys` are not really related to "the config file", so while the name `hostmgr config` for that command could still work when interpreted as "configure hostmgr to make it work", this still feels a bit odd

### Proposal 2️⃣ : Move everything under `hostmgr setup`

| Old | New |
|---|---|
| `hostmgr set automatic-login-password` | `hostmgr setup automatic-login-password` |
| `hostmgr install hostmgr-helper` | `hostmgr setup install-helper` |
| `hostmgr init` | `hostmgr setup init-config` |
| `hostmgr config` | `hostmgr setup show-config` |
| `hostmgr sync authorized-keys` | `hostmgr setup sync-authorized-keys`

Though it has the opposite odd feeling as 1‍⃣ , where `hostmgr setup` makes sense for most of the commands but might feel odd to be used for manipulating the config file. Though imho this at least feels a bit less odd than 1‍⃣ ? 🤷

### Proposal 3‍⃣ : Split into `hostmgr config` and `hostmgr setup`

| Old | New |
|---|---|
| `hostmgr set automatic-login-password` | `hostmgr setup automatic-login-password` |
| `hostmgr install hostmgr-helper` | `hostmgr setup install-helper` |
| `hostmgr init` | `hostmgr config init` |
| `hostmgr config` | `hostmgr config` |
| `hostmgr sync authorized-keys` | `hostmgr setup sync-authorized-keys`

Means we'd still keep those commands spread in 2 subcommands instead of one, so they'd still be a bit spread out as they current are, but quite less so at least (i.e. in 2 subcommands rather than 5).
This has the benefit of getting rid of the odd feelings mentioned in 1‍⃣ and 2‍⃣ though with the commands about config file still being separated from the setup ones (but the `init` of the config file now being properly grouped with the one showing the content)…

Start with Sources/hostmgr/HostMgrCommand.swift and Sources/hostmgr/SyncCommand.swift to map the existing command hierarchy, then inspect GenerateCommand.swift for the RunCommand naming inconsistency. Review the three proposed command layouts and confirm the intended one with maintainers before changing command names or structure; done means the selected hierarchy is implemented consistently and the generate command type is correctly named.

Written by the indexing model from the issue text.