cloud: Allow cloud tests to be run in parallel

backend/oss: Supports the new attribute sts_endpoint

nullable variable docs

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>

Add the `-parallel N` switch to tell the tests to run in N processes:

```
TFE_TOKEN=$TFE_TOKEN TFE_HOSTNAME=$TFE_HOSTNAME TF_ACC=1 go test -v \
  -tags=e2e ./internal/cloud/e2e/... -parallel 4
```

Add `nullable` to the variable documentation.
Remove "module" from the "null means omission" part of the null type
documentation.

Previously, `terraform init` was throwing an error if you configured the cloud
block with `tags` and there weren't any tagged workspaces yet. Confusing and
alienating, since that that's a fairly normal situation! Basically TFC was
handling an empty list of workspaces worse than other backends, because it
doesn't support an unnamed default workspace.

This commit catches that condition during `Meta.selectBackend()` and asks the
user to pick a name for their first tagged workspace. If they cancel out, we
still error, but if we know what name they want, we can handle it the same way
as a nonexistent workspace specified in `name` -- just pass it to
`Meta.SetWorkspace()`, and let the workspace get implicitly created when
`InitCommand.Run()` eventually calls `StateMgr()`.

configs: explicitly nullable variable values

Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>

This is documentation for the first set of refactoring-related features,
all based on the new "moved" blocks in the Terraform language.

I've named the documentation section "refactoring" because in previous
discussions with users that seems to be the term they use to describe the
underlying need.

"moved" blocks are our first language feature intended to meet that need,
although it probably won't be the last as we consider other requirements
in later releases. My intent here is that once we've published this it
should eventually end up being the first result for a web search for the
topic of Terraform refactoring.

Based on feedback during earlier alpha releases, we've decided to move
forward with the current design for the first phase of config-driven
refactoring.

Therefore here we've marked the experiment as concluded with no changes
to the most recent incarnation of the functionality. The other changes
here are all just updating test fixtures to no longer declare that they
are using experimental features.

cloud: Fix prerelease version constraint checks

command: Adjust skipping of resource counts for any remote implementation

Flatten `assume_role` block for OSS backend 

When using the Terraform Cloud integration - like the 'remote'
backend - resource count output should be suppressed if those counts are
being rendered remotely. This generalizes this to the shared
BackendWithRemoteTerraformVersion interface.

remove Crash section of issue template

Terraform is no longer going to silently capture all logs for a possible
crash report, and therefor won't create a crash.log file when a panic is
encountered.

The prompt to create a log file with TF_LOG from the Debug Output
section should suffice to get users to submit the logs when possible. In
the case of a crash specifically, the crash output also requests that
the stack trace be added to the issue for users who may not be aware of
what is necessary.

Remove the use of panicwrap in the Terraform CLI

The current behavior of module input variables is to allow users to
override a default by assigning `null`, which works contrary to the
behavior of resource attributes, and prevents explicitly accepting a
default when the input must be defined in the configuration.

Add a new variable attribute called `nullable` will allow explicitly
defining when a variable can be set to null or not. The current default
behavior is that of `nullable=true`.

Setting `nullable=false` in a variable block indicates that the variable
value can never be null. This either requires a non-null input value, or
a non-null default value. In the case of the latter, we also opt-in to
the new behavior of a `null` input value taking the default rather than
overriding it.

In a future language edition where we make `nullable=false` the default,
setting `nullable=true` will allow the legacy behavior of `null`
overriding a default value. The only future configuration in which this
would be required even if the legacy behavior were not desired is when
setting an optional+nullable value. In that case `default=null` would
also be needed and we could therefor imply `nullable=true` without
requiring it in the configuration.

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