provider/terraform: Terraform-specific encoding functions tfvarsencode, tfvarsdecode, and exprencode

[apparentlymart]

Using the new possibility of provider-contributed functions, this introduces three new functions which live in the
terraform.io/builtin/terraform provider, rather than being language builtins, due to their Terraform-domain-specific nature and the fact that they should not be needed by most Terraform module authors.

The three new functions are:

• tfvarsencode: takes a mapping value and tries to transform it into Terraform CLI's "tfvars" syntax, which is a small subset of HCL that only supports key/value pairs with constant values.
• tfvarsdecode: takes a string containing content that could potentially appear in a "tfvars" file and returns an object representing the raw variable values defined inside.
• exprencode: takes an arbitrary Terraform value and produces a string that would yield a similar value if parsed as a Terraform expression.

All three of these are very specialized, of use only in unusual situations where someone is "gluing together" different Terraform configurations etc when the usual strategies such as data sources are not suitable. There's more information on the motivations for (and limitations of) each function in the included documentation.

For most situations, it would be better for an author to use the existing jsonencode or yamlencode function, to produce formats that are relevant outside of Terraform.

As with all of the existing functionality of this built-in provider, these functions double both as solutions to real (but unusual/specialized) use-cases, and just as some built-in examples of provider-contributed functions in general that we can conveniently use for testing and minimal reproduction cases for bugs.

Closes #25584 and provides a more comprehensive workaround for hashicorp/terraform-provider-tfe#188 and hashicorp/terraform-provider-tfe#433.

(Hopefully at some future point the hashicorp/tfe provider will offer the option of providing input variables as a dynamically-typed argument encoded by the provider itself, rather than requiring the author to encode it explicitly, but this seems like a pragmatic alternative that doesn't raise so many awkward design questions.)

[apparentlymart]

I've intentionally excluded an exprdecode here because we have no known real use-case for it and it would amount to a weirdly-restrictive "eval"-type function that doesn't allow any function calls or references. If we do ever find a desire to add such a function then it should probably live as part of the main language so that it would be able to integrate with the module that it's used in, and refer to other symbols declared in it.

[apparentlymart]

I've left this as a draft for now because it will need to be revised slightly once #34603 is merged, to remove the current finagling from error to diagnostic and then back to error again.

[apparentlymart]

This is now updated for #34603, by removing the few spots where it was previously twiddling from error to tfdiags and then back to error again.

[github-actions]

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.