cty now requires Go 1.23, because package iter is not available in earlier
versions of Go.

Having now got some experience using marks more extensively in some
callers, it's become clear that it's often necessary for different
subsystems to be able to collaborate using independent marks without
upsetting each other's assumptions. Today that tends to be achieved using
hand-written transforms either with cty.Transform or
cty.Value.UnmarkDeepWithPaths/cty.Value.MarkWithPaths, both of which can
be pretty expensive even in the common case where there are no marks
present at all.

This new function allows inspecting and transforming marks with far less
overhead, by creating new values only for parts of a structure that
actually need to change and by reusing (rather than recreating) the
"payloads" of the values being modified when we know that only the marks
have changed.

I've seen variants of each of these hand-written many times in callers, so
it's well past time to bring them upstream to better support the common
marks-related usage patterns that have emerged downstream.

Go 1.18 introduced "any" as a shorthand for the empty interface type, and
we'd already started using it in a few places so for consistency let's
switch all existing uses of empty interface to "any" now.

An earlier commit added cty.DeepValues as an iter.Seq2-based alternative
to Walk, and that's much easier to use for deep inspections because it
doesn't require weird trickery to get the Walk to stop at the right time
and smuggle result values out.

However, in the process of doing this I discovered that cty.DeepValues
itself was falling into that very trap of failing to terminate Walk
correctly, and so this also includes a fixed version of that which will
stop yielding new values once commanded to do so.

These functions were previously using the "Transformer" mechanism, which is
very general but as a result ends up always conservatively rebuilding
the entire data structure it's given.

The recently-added WrangleMarksDeep relies on the fact that it can only
possibly change marks (not the actual values) to avoid building a new
value at all in the common case where there are no marks, to rebuild
only the parts of the structure that have mark changes when changes are
being made, and to reuse the internal "payload" values from the source
values while just wrapping them in a new outer cty.Value.

Testing with a benchmark in another codebase that makes heavy use of both
UnmarkDeep and UnmarkDeepWithPaths shows this being a material performance
improvement.

This also includes a bonus fast path for MarkWithPaths where it will skip
doing anything at all if the given slice of ParkValueMarks is empty.