website: Remove warning that yamlencode is experimental

We originally included this warning because the go-cty-yaml module wasn't
yet stable and it was also not extensively tested so it wasn't yet clear
if its behavior would need to change in some less common cases we hadn't
tested so far.

However, go-cty-yaml had its v1.0.0 release some time ago and is now
committed to preserving its current Marshal output unless it is found to
be non-compliant with the YAML 1.2 specification. This doc change means
that Terraform's yamlencode is now adopting a similar posture:
 - The exact style details produced by the function for a particular input
   are now frozen. It'll change only if we find that the function is
   producing output that isn't valid per the YAML spec.
 - If someone finds a YAML parser that cannot parse what yamlencode
   produces but what it produces is valid per the YAML 1.2 spec, we'll
   expect the parser to be corrected to better support the spec rather
   than changing the yamlencode output.

There may be pragmatic exceptions if we encounter a situation we cannot
anticipate yet, but the above will be our general rule. This is really
just a specialization of the spirit of the v1.x Compatibility Promises,
tailored specifically to this function.

website/docs/language/functions/yamlencode.mdx

@@ -8,23 +8,6 @@ description: The yamlencode function encodes a given value as a YAML string.
 `yamlencode` encodes a given value to a string using
 [YAML 1.2](https://yaml.org/spec/1.2/spec.html) block syntax.
 
-~> **Warning:** This function is currently **experimental** and its exact
-result format may change in future versions of Terraform, based on feedback.
-Do not use `yamldecode` to construct a value for any resource argument where
-changes to the result would be disruptive. To get a consistent string
-representation of a value use [`jsonencode`](/language/functions/jsonencode) instead; its
-results are also valid YAML because YAML is a JSON superset.
-
-<!--
-    The condition for removing the above warning is that the underlying
-    go-cty-yaml module makes a stable release with a commitment to guarantee
-    that the representation of particular input will not change without a
-    major release. It is not making that commitment at the time of writing to
-    allow for responding to user feedback about its output format, since YAML
-    is a very flexible format and its initial decisions may prove to be
-    sub-optimal when generating YAML intended for specific external consumers.
--->
-
 This function maps
 [Terraform language values](/language/expressions/types)
 to YAML tags in the following way:
@@ -49,6 +32,15 @@ types, passing the `yamlencode` result to `yamldecode` will not produce an
 identical value, but the Terraform language automatic type conversion rules
 mean that this is rarely a problem in practice.
 
+YAML is a superset of JSON, and so where possible we recommend generating
+JSON using [`jsonencode`](/language/functions/jsonencode) instead, even if
+a remote system supports YAML. JSON syntax is equivalent to flow-style YAML
+and Terraform can present detailed structural change information for JSON
+values in plans, whereas Terraform will treat block-style YAML just as a normal
+multi-line string. However, generating YAML may improve readability if the
+resulting value will be directly read or modified in the remote system by
+humans.
+
 ## Examples
 
 ```