A more native integration for Terraform Cloud and its CLI-driven run workflow.

Instead of a backend, users declare a special block in the top-level terraform settings
block to configure Terraform Cloud, then run terraform init.

Full documentation will follow in later commits.

The previous version is a little overdramatic and somewhat accusatory.
Just lay it out how it is: TFC needs workspaces to be named.

This can help differentiate cloud integration API requests from normal remote backend requests

When the 'select the exact version if possible' behavior was added, the
version check below it was never updated to take the newly updated
version in to account, resulting in a failed version check even as the
remote workspace updated to the correct version necessary.

E2E tests including cost estimation should indeed be added, but the
default case should be disabled; lots of cycles lost to pointless cost
estimates on null and random resources.

This aligns more with the existing copy for backends

The delete + assign at the end of `Update` and `UpdateByID` are meant to handle
renaming a workspace — (remove old name), (insert new name).

However, `UpdateByID` was doing (remove new name), (insert new name) and leaving
the old name in place. This commit changes it to match `Update` by grabbing the
original name off the workspace object _before_ potentially renaming it.

Alas, there's not a very good way to test the message we're supposed to print to
the console in this situation; we just don't appear to have a mock terminal that
the test can read from. But we can at least test that the function returns
without erroring under the exact conditions where it was erroring before.

Note that the behaviors of mc.Workspaces.Update and UpdateByID were already
starting to drift, so I consolidated their actual attribute update logic into a
helper function before they drifted much further.

Previously, if the remote TFC/TFE instance doesn't happen to have a tool_version
record whose name exactly matches the value of `tfversion.String()`, Terraform
would be completely blocked from using the `terraform workspace new` command
(when configured with the tags strategy) — the API would give a 422 to the
whole create request.

This commit changes the StateMgr() function to do the work in two passes; first
create the workspace (which should work fine regardless), THEN update the
Terraform version and print a warning to the terminal if it fails (which 99% of
the time is a benign failure with little impact on your future CLI usage).

If you move from the remote backend to the cloud block you will see this
error message.

There are actually a few different ways to get to this message.

1. Blank state — no previous terraform applied. Start with a cloud block.
1. Implicit local — start with no backend specified. This actually goes
   through the same code execution path as the first scenario.
1. Explicit local — start with a backend local block that has been
   applied, then change from the local backend to a cloud block. This
   will recognize the state, and is a different path through the code in
   the meta backend.

This commit handles the last case. The messaging has also been tweaked.

End to end test included as well.

https://app.asana.com/0/1199201948575144/1201019450474843/f

* Add test for tfc to tfc mgiration
* Fix old tests, and remove unused code.

* Update e2e tests to specify Terraform Cloud
* Update more of the terraform command flow to specify Terraform Cloud

* Handle when there are multiple workspaces migrating to cloud,
using both the cloud name strategy and cloud tags strategy.
* Add e2e tests

Explicit version strings are actually also version constraints! And the special
comparisons we were doing to allow a range of compatible versions can also be
expressed as version constraints.

Bonus: also simplify the way we handle version check errors, by composing the
messages inline and only extracting the repetitive parts into a function.