Deprecate sets in favor of uniqueItems

[mtdowling]

This commit is a reversal of a previous decision to deprecate
uniqueItems. This reversal is due to an observation that sets
aren't all that useful or desirable for client/server scenarios,
which is the primary use case for Smithy.

First, we added a requirement that sets maintain insertion order.
This was to guarantee that validation errors returned by servers
are actionable by clients. If a client and server don't agree on
what element 0 means, then a client doesn't know which value in
their unordered set is incorrect.

Next, we limited what kinds of values can be stored in a set because
some types like float makes equality checks in languages like Rust
difficult. We also realized that clients with imperfect knowledge
of a model (which is basically all clients) often drop unknown
structure members. If a server sends two structures to a client
and one of the structures uses a member the client doesn't know
about, the client will drop the member, and then drop the second
structure because it considers it a duplicate of the first.

So at this point, we realized that sets are more confusing than
useful. The ideal state is that clients ignore unique-ness
constraints and leave that to servers to perform as validation
and not as part of the type system. It turns out, that's exactly
the use case of the @Uniqueitems trait.

So instead of removing the @Uniqueitems trait, we're doubling
down on it. The trait can once again target any kind of type
(except for float, double, and document), we're defining how to
determine equality, order is implicit because the trait targets a
list, and the fact that this is validation and not type
refinement is implicit because it is a "constraint trait".

Sets will be removed from IDL v2.

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.