As usual with marks, we must panic whenever an operation might cause marks
to be silently lost. In such cases, it's always the calling application's
responsibility to unmark the value first and then ensure that it applies
the appropriate derived marks to whatever new value it's ultimately
returning based on the decision.

This was already a panic before, but now it's a panic with an explicit
message pointing directly at the problem.

For historical reasons we cannot permit any refinements on cty.DynamicVal,
because existing callers expect that (marks notwithstanding) cty.DynamicVal
is the only possible unknown value of an unknown type, and so adding
refinements would invalidate that assumption.

In the initial implementation of refinements it was treated as a caller
programming error to try to refine cty.DynamicVal. However, that violates
the convention that cty.DynamicVal is usable as a broad placeholder value
that supports any operation that would be valid on at least one possible
value.

Instead, we'll now compromise by just silently ignoring any attempt to
refine cty.DynamicVal. The refinement operation will run to completion
without panicking but it will also completely ignore all of the refinement
builder calls and eventually just return another plain cty.DynamicVal
as the "refined" result.

This is consistent with our typical expectation that refinements are
propagated on a best-effort basis but can be silently discarded (or lose
some detail) when passing through operations that don't or can't support
them.

This means that it should now be safe to call Refine on any value, but
refining can still panic if the specific refinements selected don't make
sense for whatever value is being refined.

This also includes some direct tests of the Value.Refine API, since it
was previously only tested indirectly through other operations that
consume or manipulate refinements.