Structure and minimize console output during cluster deployment

[stmcginnis]

Describe the feature request

The output should be grouped based on the high level steps of the process. So
rather than the current:

Doing something.
Start creating cluster...
Saving file.
Installing xyz
Waiting for x...

All output is at the same level and there is no differentiation or
relevance of each log line. The new output should have clear high level steps:

☑️  Determining cluster settings
   [specific useful details]
☑️  Performing step 2
   [specific useful details]
☑️  Performing step 3
   [specific useful details]

Emojis may vary to help relate to the type of step being performed - the ☑️
above is for illustration purposes only.

The amount of lines should be minimized. No output should be given if it does
not directly help the user understand what they need to know.

With the output grouped into the high level sections as described above,
within those high level sections there should be specific and useful details
for the user. Output from the currently recently added TCE unmanaged-cluster
creation provides a good example of this:

🎨 Selected base image
   projects.registry.vmware.com/tce/kind/node:v1.21.5
📦 Selected core package repository
   projects.registry.vmware.com/tkg/packages/core/repo:v1.21.2_vmware.1-tkg.1
📦 Selected additional package repositories
   projects.registry.vmware.com/tce/main:0.9.1
📦 Selected kapp-controller image bundle
   projects.registry.vmware.com/tkg/packages/core/kapp-controller:v0.23.0_vmware.1-tkg.1
📧 Installing package repositories
   Core package repo status: Reconcile succeeded
🌐 Installing CNI
   antrea.tanzu.vmware.com:0.13.3+vmware.1-tkg.1
✅ Cluster created

Output is minimal, and can be skipped altogether if there isn't anything useful
for the end user to know.

Overall Principles

• Review and group current output into high level steps
• Only emit specific details related to the high level steps
• Review all output and ensure it is at an appropriate log level
  • Low level details should be at a higher verbosity level so they are not
    seen unless requested
  • What is emitted at normal logging levels should be reviewed for its
    usefulness
  • All output should be reviewed and removed from normal output if it only
    serves as development tracing of code paths (but still included when high
    verbosity is used for tracing purposes)

Describe alternatives you've considered

Output could be less structured and we could just review what things are logged at the default level. This is less readable though.

Affected product area (please put an X in all that apply)

• APIs
• Addons
• CLI
• Docs
• IAM
• Installation
• Plugin
• Security
• Test and Release
• User Experience

Additional context