refactor: Add methods to init command's view implementations for logging about progress of initialising the working directory

[SarahFrench]

This PR adds methods to the views package's Init interface for logging messages related to the progress of initialising the working directory:

1. Initialization is starting (only used for cloud backend)

• Text Initializing HCP Terraform...
• JSON message code: initializing_terraform_cloud_message

2. Initialization completes

• Text Terraform has been successfully initialized! OR Terraform initialized in an empty directory!
• JSON message code: output_init_success_message OR output_init_empty_message

3. Calls to action shown to those using the CLI directly after successful init

• Text You may now begin working with Terraform...
• JSON message code: output_init_success_cli_message

4. Calls to action shown to those using the CLI to managed HCP Terraform directly after successful init

• Text You may now begin working with HCP Terraform...
• JSON message code: output_init_success_cli_cloud_message

Design decisions

In future, fewer JSON types could be used and nuances described via other fields.

I combined logging Terraform has been successfully initialized! and Terraform initialized in an empty directory! to the same method as I imagine that a future JSON object representing initialisation of a working directory could be type = a more generic init_complete and then distinguish between whether the config was empty or not using fields in the JSON (and different human-readable summaries of the object).

This could be extended to allow cloud and non-cloud versions of a message to be made from a single method, but I figured that was over-optimisation for this stage.

Using language that matches how other structured logging/SRO is implemented

In plan/apply's JSON logging the message types have conventions of _start, _progress, _complete, _errored as shared suffixes for JSON object types.

The init command produces structured logging/SRO but doesn't follow these conventions. The method names in this PR attempt to do this, and hopefully in future we can make changes to the JSON objects themselves (breaking change tho 😭).

Target Release

1.17.x

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.