Not sure why this got included.

Fix some panics because I didn't run _all_ the tess, like a dolt.

Introduced some import errors while rebasing. Now they're fixed.

Make sure that ProviderMeta gets sent to providers for RPC calls for
data sources.

Test to make sure that destroy ApplyResourceChange requests get the
ProviderMeta field set during RPC.

Make sure to pass ProviderMeta when doing refresh RPC calls.

Set the ProviderMeta value when planning resource changes, and add a
test to ensure that it's getting set properly.

We want ProviderMeta information to be available to the provider during
all the RPC calls, so extend the protocol to account for that, and fill
out all the needed methods.

Figure out how to test provider_meta, and write our first test, a basic
check that the value will be delivered as part of the
ApplyResourceChange request when set. Still a lot of test cases that
need testing.

We weren't passing provider meta information on destroy, now we attach
it to nodes for resource destruction, which should let it get sent along
as necessary.

Actually initialize the ProviderMetas map for the Module when calling
configs.NewModules so we don't panic.

Check the NodeValidatableResource implements
GraphNodeAttachProviderMetaConfigs.

When calling terraform.loadProviderSchemas, actually set the
ProviderMeta block.

Add ProviderMeta to state. For some reason? I don't know why.

Fix the ProviderTransformer to use the ProviderConfig.Type instead of
String() output for the provider when looking up the ProviderMeta to
use.

Now if a provider doesn't support provider_meta and somehow we miss that
at validation time, the user will get an error with more details and
pointing to the specific provider_meta declaration that is a problem.

Add the ProviderMeta field to the EvalValidateResource type so we can
check that the HCL for the resource's provider's provider_meta block is
valid.

Add a code note about why we're doing this in the resource block instead
of somewhere that makes more sense.

A pass at implementing module attribution ("provider_meta blocks in the
terraform block", whatever, it's for module attribution).

The general idea is that we're adding a new ProviderMeta struct to our
configs package, which is then added to Files, Modules, and parsed as
part of the terraform block.

The configs.Config type then makes that available to the
terraform.ProviderTransformer type, which is already scoped by module.
It picks out the ProviderMeta for the provider we need in its Transform
method, and checks to see if the node it's working on implements the
terraform.GraphNodeAttachProviderMetaConfigs interface, which is a new
interface we're adding. It has only one method:
AttachProviderMetaConfigs, which is passed a *configs.ProviderMeta.

We implement this on the terraform.NodeAbstractResource type, storing
the passed *configs.ProviderMeta in a new property on that struct.

That struct is eventually made available to the
terraform.NodeApplyableResource...

Update taint docs - for_each

For remote operations, the remote system (Terraform Cloud or Enterprise)
writes the stored variable values into a .tfvars file before running the
remote copy of Terraform CLI.

By contrast, for operations that only run locally (like
"terraform import"), we fetch the stored variable values from the remote
API and add them into the set of available variables directly as part
of creating the local execution context.

Previously in the local-only case we were assuming that all stored
variables are strings, which isn't true: the Terraform Cloud/Enterprise UI
allows users to specify that a particular variable is given as an HCL
expression, in which case the correct behavior is to parse and evaluate
the expression to obtain the final value.

This also addresses a related issue whereby previously we were forcing
all sensitive values to be represented as a special string "<sensitive>".
That leads to type checking errors for any variable specified as h...

Previously any error case in the Context method would cause us to leave
the remote workspace locked on exit, requiring manual action to unlock it.

[Website] CherryServer doc links

Resource value may be an object in self evaluation

The fallback type for GetResource from an EachMap is a cty.Object,
because resource schemas may contain dynamically typed attributes.
Check for an Object type in the evaluation of self, to use the proper
GetAttr method when extracting the value.

These are often confusing for new contributors, since this looks
suspiciously like the right place to add new functions or change the
behavior of existing ones.

To reduce that confusion, here we remove them entirely from this package
(which is now dead code in Terraform 0.12 anyway) and include in the
documentation comments a pointer to the current function implementations.

Previously we were inconsistent in whether we were recommending the
new required_providers block or the "version" setting inside a "provider"
block.