remove unmaintained etcd backend to update grpc packages

Added example with function argument expansion

There are no good options for inserting diagnostics into the backend
lookup, or creating a backend which reports it's removal because none of
the init or GetSchema functions return any errors.

Keep a registry of the removed backend so that we can at least notify
users that a backend was removed vs an invalid name.

Update READMEs to help folks figure out how to successfully make docs

Co-authored-by: Kevin Wang <kwangsan@gmail.com>

Update apply page for style, concision, and clarity

Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com>

Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com>

Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com>

Co-authored-by: Nick Fagerlund <nick.fagerlund@gmail.com>

This allows us to remove the manual replace directives
github.com/dgrijalva/jwt-go and google.golang.org/grpc, so that we can
remove the CVE warnings and update the grpc packages.

While the etcdv3 backend is also marked as deprecated, the changes here
are done in a manner to keep that backend working for the time being.

* Clarify how the ~> version contraint operator works

* add comma, clarify the actor

* verbiage tweak

* language cleanup from PR review
Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com>

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

By observing the sorts of questions people ask in the community, and the
ways they ask them, we've inferred that various different people have been
confused by Terraform reporting that a value won't be known until apply
or that a value is sensitive as part of an error message when that message
doesn't actually relate to the known-ness and sensitivity of any value.

Quite reasonably, someone who sees Terraform discussing an unfamiliar
concept like unknown values can assume that it must be somehow relevant to
the problem being discussed, and so in that sense Terraform's current
error messages are giving "too much information": information that isn't
actually helpful in understanding the problem being described, and in the
worst case is a distraction from understanding the problem being described.

With that in mind then, here we introduce an explicit annotation on
diagnostic objects that are directly talking about unknown values or
sensitive values, and then the diagnostic renderer will react to that to
avoid using the terminology "known only after apply" or "sensitive" in the
generated diagnostic annotations unless we're rendering a message that is
explicitly related to one of those topics.

This ends up being a bit of a cross-cutting concern because the code that
generates these diagnostics and the code that renders them are in separate
packages and are not directly aware of each other. With that in mind, the
logic for actually deciding for a particular diagnostic whether it's
flagged in one of these special ways lives inside the tfdiags package as
an intermediation point, which both the diagnostic generator (in the core
package) and the diagnostic renderer can both depend on.

When an error occurs in a function call, the error message text often
includes references to particular parameters in the function signature.

This commit improves that reporting by also including a summary of the
full function signature as part of the diagnostic context in that case,
so a reader can see which parameter is which given that function
arguments are always assigned positionally and so the parameter names
do not appear in the caller's source code.

HCL's diagnostic model now includes the idea of "extra information" which
works by attaching an initially-opaque interface value to each diagnostic
and then asking callers to type-assert against that value to sniff for
particular interfaces in order to discover additional machine-readable
context about a certain diagnostic message.

This commit echoes that idea into our tfdiags API, for now only for
diagnostics that are backed by an hcl.Diagnostic. All other implementations
of the diagnostic interface just always return nil, which means they never
carry any "extra information".

As is typical for our wrapping abstraction, we have here also a modified
copy of HCL's helper function for conveniently probing a diagnostic for
information of a particular type, designed to work with our diagnostic
interface instead of HCL's concrete diagnostic type.

Use plan graph for importing resources

Performance: string builder speedup for Module.String()

Missing required attributes should not prevent importing

configs: Fix check block configuration diagnostics

making code more similar to https://github.com/hashicorp/terraform/blob/main/internal/addrs/module_instance.go

When validating self-references for resource and data source
preconditions and postconditions, we previously did not nil-check the
block's condition field, which caused a panic when the block had no
condition.

While fixing this I noticed that we were not validating that there are
no self-references in the error message, so fixed that.