internal/fwschemadata: Rewrite SetValue semantic equality logic to ignore order

[austinvalle]

Closes #1061

This PR fixes the set semantic equality logic, which prior to this change, was written equivalent to list semantic equality.

Sets are unordered, so to correctly compare the semantic equality of two sets, we must compare each element in the set against all other elements to determine if there is a semantically equivalent element in the set. Once we find a semantically equal element, we remove it from the slice of candidates and continue.

---

As an example, consider a set of case insensitive strings.

With the previous logic, the following sets would be considered semantically equal:

["value-a", "value-b", "value-c"]
["VALUE-A", "VALUE-B", "VALUE-C"]

However the following set would be incorrectly considered semantically not equal, due to the difference in order:

["value-a", "value-b", "value-c"]
["VALUE-B", "VALUE-C", "VALUE-A"]

This change will result in both of these examples being considered semantically equal.

Corner tests

I also wrote some acceptance tests to make it a little easier to understand the impact (using IPv6 address strings as an example)

hashicorp/terraform-provider-corner#297

Unit test failures before the fix

https://github.com/hashicorp/terraform-plugin-framework/actions/runs/12832297072/job/35784696031?pr=1064

--- FAIL: TestValueSemanticEqualitySet (0.00s)
    --- FAIL: TestValueSemanticEqualitySet/SetValue-SetValue-StringValuableWithSemanticEquals-true-diff-order (0.00s)
        value_semantic_equality_set_test.go:1021: unexpected difference:   &fwschemadata.ValueSemanticEqualityResponse{
            - 	NewValue:    s`[["KEEP-LOWERCASE-012","KEEP-LOWERCASE-789"],["KEEP-LOWERCASE-456","KEEP-LOWERCASE-123"]]`,
            + 	NewValue:    s`[["keep-lowercase-123","keep-lowercase-456"],["keep-lowercase-789","keep-lowercase-012"]]`,
              	Diagnostics: nil,
              }
    --- FAIL: TestValueSemanticEqualitySet/SetValue-StringValuableWithSemanticEquals-true-diff-order (0.00s)
        value_semantic_equality_set_test.go:10[21](https://github.com/hashicorp/terraform-plugin-framework/actions/runs/12832297072/job/35784696031?pr=1064#step:5:22): unexpected difference:   &fwschemadata.ValueSemanticEqualityResponse{
            - 	NewValue:    s`["KEEP-LOWERCASE-456","KEEP-LOWERCASE-123"]`,
            + 	NewValue:    s`["keep-lowercase-123","keep-lowercase-456"]`,
              	Diagnostics: nil,
              }

[austinvalle]

̶S̶i̶n̶c̶e̶ ̶w̶e̶ ̶h̶a̶v̶e̶ ̶w̶r̶i̶t̶e̶-̶o̶n̶l̶y̶ ̶a̶t̶t̶r̶i̶b̶u̶t̶e̶s̶ ̶l̶a̶n̶d̶i̶n̶g̶ ̶s̶o̶o̶n̶,̶ ̶t̶h̶i̶s̶ ̶b̶u̶g̶ ̶f̶i̶x̶ ̶w̶i̶l̶l̶ ̶g̶o̶ ̶i̶n̶ ̶a̶f̶t̶e̶r̶ ̶i̶n̶ ̶̶v̶1̶.̶1̶4̶.̶1̶̶

Now planning on going with write-only attributes in v1.14.0

[bbasata]

I read line-by-line through internal/fwschemadata/value_semantic_equality_set.go a couple times until it tangibly clicked with me what semantic equality is about -- that was my first challenge. "Why does equality modify values?" Oh, ok! Now I want to call it "prior state prevails when the difference is cosmetic" 😃

With that, I think I have unlocked the power-up needed to review the PR 😃

[bbasata]

Once we find a semantically equal element, we remove it from the slice of candidates and continue.

Non-blocking for merge, simply a consideration: is this for optimization or correctness? I'm guessing optimization -- I think the behavior is still correct without doing this.

Related: A set might contain the same value more than once. Or multiple semantically-equal values. And I imagine it's a Hard (and unnecessary) Problem to make any promise about the behavior in that case. If the behavior mattered in that scenario, we'd likely advise folks to use a List.

[bbasata]

[bbasata]

I see the CI / lint Action wants something from us -- I'm happy to stamp this again if/when needed.

[austinvalle]

Will create a new PR for lint deprecations since it's gonna be noisy and unrelated to these changes 👍🏻