Backport of go.mod: go get github.com/zclconf/go-cty@v1.11.0 into v1.2

[teamterraform]

Backport

This PR is auto-generated from #31675 to be assessed for backporting due to the inclusion of the label 1.2-backport.

WARNING automatic cherry-pick of commits failed. Commits will require human attention.

The below text is copied from the body of the original PR.

---

This fixes a possible panic in what Terraform calls the "flatten" function in situations where a user passes in a null value of a sequence type. The function will now treat that the same as a null value of any other type.

This also includes some other changes that would benefit Terraform:

• cty: Improved performance when comparing nonzero numbers to zero, by performing a relatively-cheap sign check on both numbers before falling back on the more expensive general equality implementation. (#125)
• convert: Unify will no longer panic when asked to find a common base type for a tuple type and a list of unknown element type, and will instead just signal that such a unification is not possible. (#126)

Also notable is that this new release of cty now requires Go 1.18 or later. That's okay for backport into Terraform v1.2, since that release already uses Go 1.18, but this would not be backportable to older Terraform CLI releases. Our backport policy doesn't typically require us to go back further than one minor release anyway (aside from exceptional cases such as security advisories) and so I think this is a moot point, but I mention it for completeness.

Fixes #31376.

[hashicorp-cla]

All committers have signed the CLA.

[apparentlymart]

The version of stringer we're currently using on the v1.2 branch seems to be too old to have golang/go#51629 fixed, so I'm also going to update to the latest stringer release here so that go generate can still succeed even though we now have a package which is using type parameters in our dependency graph. (It seems like this would've happened the first time we introduced any dependency using type parameters; just coincidence that go-cty happened to be the first one.)

[apparentlymart]

Since this ended up being more than just a trivial backport I'm going to request code review in case someone knows of a reason we might not want to upgrade these various golang.org/x/... modules that came in as a side-effect of upgrading golang.org/x/tools to get a working stringer.

I don't see anything immediately concerning and those modules are have typically been conservative in their changes in the past, but with it not being the Go standard library and therefore not subject to the 1.0 Compatibility Promises I have a certain unease about it even though the tests are all still passing. 😖

[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.