This massive PR implements the mixins proposal.

The idea of redefining inherited members was removed, along with the
special `(inherit)` syntax. Feedback on this syntax was that it was
awkward. Redefining a member is now prohibited. instead, only apply is
allowed. To make it easier to apply multiple traits to a single shape,
particularly a member, a block form of apply was added in a previous
commit.

This change adds:
1. The ability to create mixins using the `@mixin` trait.
2. The ability to restrict which members are inherited by shapes that
   use a mixin using `localTraits` on the `@mixin` trait.
3. The ability to use a mixin with a shape in the IDL using `with`.
4. The ability to use a mixin in the JSON AST using `mixins`.
5. The ability to serialize mixins in the IDL and AST.
6. The ability to query mixin relationships in selectors using the
   `mixin` relationship. This also ensures that mixins are considered
   part of a service closure.
7. The ability to remove mixins from a model, and update all shapes that
   depend on the mixin.
8. The ability to "flatten" mixins out of the model, meaning that the
   mixin is removed, but any members or traits it provides to shapes
   that use it are copied onto those shapes.
9. Validation to ensure no mixin cycles or "with" statements are added
   that point to shapes that don't exist or that aren't marked with
   the `@mixin` trait.
10. Mixins are flattened out of models when converting to JSON Schema
    and to OpenAPI.
11. When a mixin is updated, any shape that uses that mixin is also
    updated.

Implementation notes:
* Mixins were added to the Shape type. This made it far easier to
  implement everything rather than introducing something like a
  `HasMixins` interface implemented on structure, union, and member
  shapes or using visitors. This design decision is similar to what was
  already done with the `members()` method on `Shape`, which just makes
  `Shape` generally easir to use.
* Shapes implicitly hold on to references to their mixins, but the mixin
  shapes are not directly exposed in the shape's API (only ShapeIds).
  This ensures that if we need to do any refactoring later, we can
  without making that a hard design requirement (it isn't so far!).
* Missing validation about member shapes matching their container IDs
  was added because it was needed to ensure mixin members were added
  correctly.
* An updated ListUtils.of() method was added for the case when there are
  two items. This was done because the `members()` method is now used
  each time a shape is created, which previously created an ArrayList
  each time the members of MapShape were requested.