Apologies for not creating an issue first but it seemed like a simple docs change. 

`apt install terraform` requires the  `apt update` before terraform can be installed.

fix(run variables): support all variable types (map, list, bool, number, null, string)

All run variables remain encoded as strings in the API but will now be expressed as an HCL value to be evaluated correctly by the remote terraform. Previously, only strings were supported.

Examples:
string: `"quoted literal"` (strings must be quoted)
map:  `{ foo = "bar" }`
list: `["foo", "bar"]`
bool: `true`
null: `null`
number: `0.0001`

This requires the API to anticipate that all run variables will be HCL values

Pull changes made to mocks in go-tfe

command: make module installation interruptible

Error diags from c.installModules() no longer cause getModules() to exit early.
Whether installModules completed successfully, errored, or was cancelled, we
try to update the manifest as best we can, preferring incomplete information
to none.

Earlier work to make "terraform init" interruptible made the getproviders
package context-aware in order to allow provider installation to be cancelled.

Here we make a similar change for module installation, which is now also
cancellable with SIGINT. This involves plumbing context through initwd and
getmodules. Functions which can make network requests now include a context
parameter whose cancellation cancels those requests.

Since the module installation code is shared, "terraform get" is now
also interruptible during module installation.

Command state mv: Error when backup or backup-out options are used without the state option on non-local backends

Error if backup or backup-out options are used without the state option on non-local backends for the state mv command

* convert uses of worspaces.operations into workspaces.executionMode

The cloud package currently uses a deprecated API on workspaces to determine a workspace's execution mode.

Deprecated: Operations (boolean)
New hotness: Execution mode (string - "local", "remote", or "agent")

More details: https://www.terraform.io/docs/cloud/api/workspaces.html#request-body



All uses of Operations field coming from the client (within the cloud package) should be converted to the appropriate ExecutionMode equivalent.
Also, we need to update all acknowledgment of operations field on the tests that are testing the behavior of workspaces.
Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com>
Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com>

We have a few dependencies that are such a significant part of Terraform's
behavior that they will often be the root cause of or the solution to a
bug reported against Terraform.

As a small quality-of-life improvement to help with diagnosing those,
we'll now report the selected versions for each of these so-called
"interesting" dependencies as part of our initial trace log output during
Terraform startup.

The goal here is that when someone opens a bug report, and includes the
trace log as our bug report template requests, we'll be able to see at a
glance which versions of these dependencies were involved, instead of
having to manually cross-reference in the go.mod file of the reported main
Terraform CLI version.

This does slightly grow the general overhead of the logs, but as long as
we keep this set of interesting dependencies relatively small it shouldn't
present any significant problem in typical usage.

Fix typo in 0.13 upgrade guide

cloud: Add streamlined 'remote' backend state migration path

For Terraform Cloud users using the 'remote' backend, the existing
'pattern' prompt should work just fine - but because their workspaces
are already present in TFC, the 'migration' here is really just
realigning their local workspaces with Terraform Cloud. Instead of
forcing users to do the mental gymnastics of what it means to migrate
from 'prefix' - and because their remote workspaces probably already exist and
already conform to Terraform Cloud's naming concerns - streamline the
process for them and calculate the necessary pattern to migrate as-is,
without any user intervention necessary.

cloud: Autoselect migrated current workspace + migrate UX adjustments

After migrating to TFC with renamed workspaces, automatically select
what was the previous current workspace on behalf of the user. We don't
need to make the user reselect.

Note these change do break the internal/cloud/e2e tests; they are in a
sad state that needs adjusting anyway, so I'm not updating them for
these changes at this time.

backend/oss: Removes the ConflictWith tag which on the attributes assume_role* to fix the incompatible error

generate precise resource types during validate

update go-cty to v1.10.0

backend/oss: Removes the ConflictWith tag which on the attributes assume_role* to fix the incompatible error

Cloud: Update Workspace during Tags strategy

cty: The documented definition and comparison logic of cty.Number is now
refined to acknowledge that its true range is limited only to values
that have both a binary floating point and decimal representation,
because cty values are primarily designed to traverse JSON serialization
where numbers are always defined as decimal strings.

In particular, that means that two cty.Number values now always compare
as equal if their representation in JSON (under cty's own JSON encoder)
would be equal, even though the decimal approximation we use for that
conversion is slightly lossy. This pragmatic compromise avoids confusing
situations where a round-trip through JSON serialization (or other
serializations that use the same number format) may produce a value that
doesn't compare equal to the original.

This new definition of equals should not cause any significant behavior
change for any integer in our in-memory storage range, but may cause
some fractional values to compare equal where they didn't before if they
differ only by a small fraction.

command: Update backend hash value only after a successful migration

The Meta.backend_C_r_S_unchanged() method was sadly a bit of a mess.

It seems to have originally been used as a method to be called
when the backend is not changing, with an extra assumption that if the
configured backend's hash doesn't match the one in state, surely the
hash should just be updated as an option might have been moved to
command line flags.

However, this function was used throughout this file as 'the method to
load the initialized (but not necessarily configured) backend',
regardless of whether or not it is the same (unchanged). This is in
addition to Meta.backendFromState(), which is used to load the same
thing except in the main codepath of 'init -backend=false'.

These changes separate the concerns of backend_C_r_S_unchanged() by

1) Fetching the saved backend (savedBackend())
2) Updating the hash value in the backend cache when appropriate (either
   by leaving it to the caller to do themselves or by calling
   updateSavedupdateSavedBackendHash())

This allows migration codepaths to *not* update the hash value until
after a migration has successfully taken place.

We only lookup providers by provider type to get the schema, so there's
no reason to generate anything more specific.

Allow `GetResource` to return correct types values during validation,
rather than relying on `cty.DynamicVal` as a placeholder. This allows
other dependent expressions to be more correctly evaluated.

Pulled and updated from
https://github.com/hashicorp/terraform/pull/26260