Beginning of Trait and Class.use

This is a rough concept showing how traits will be used at definition time
by classes (note that this does not yet address how they will be ``mixed
in'' at the time of instantiation).
Basic, incomplete, but workable traits

Note the incomplete tests. These are very important, but the current state
at least demonstrates conceptually how this will work (and is even useful in
its current state, albeit dangerous and far from ready for production).
Began implementing composition-based traits

As described in <https://savannah.gnu.org/task/index.php#comment3>.

The benefit of this approach over definition object merging is primarily
simplicitly---we're re-using much of the existing system. We may provide
more tight integration eventually for performance reasons (this is a
proof-of-concept), but this is an interesting start.

This also allows us to study and reason about traits by building off of
existing knowledge of composition; the documentation will make mention of
this to explain design considerations and issues of tight coupling
introduced by mixing in of traits.
Re-implemented mixin error for member name conflicts
Protected trait methods are now mixed in
Added tests proving traits' scopes are disjoint from classes' and each others'

This was the original motiviation behind, and is a beautiful consequence of,
the composition-based trait implementation (see
<https://savannah.gnu.org/task/index.php#comment3>).
Trait concrete class will now be lazily created on first use

This just saves some time and memory in the event that the trait is never
actually used, which may be the case in libraries or dynamically loaded
modules.
Added support for `weak' keyword

Note that, even though it's permitted, the validator still needs to be
modified to permit useful cases. In particular, I need weak abstract and
strong concrete methods for use in traits.
Added support for weak abstract methods

This adds the `weak' keyword and permits abstract method definitions to
appear in the same definition object as the concrete implementation. This
should never be used with hand-written code---it is intended for code
generators (e.g. traits) that do not know if a concrete implementation will
be provided, and would waste cycles duplicating the property parsing that
ease.js will already be doing. It also allows for more concise code
generator code.
Proxy methods may now override abstract methods

The method for doing so is a kluge; see the test case for more info.
Classes can now access trait protected members

Slight oversight in the original commit.
Implemented abstract traits

This is just an initial implementation, so there may be some quirks; there
are more tests to come.
The `weak' keyword can now apply to overrides

Well, technically anything, but we're leaving that behavior as undefined for
now (the documentation will say the same thing).
[DELETE ME] Added README.md note about branch rewriting

This commit should *not* be merged into master; remove it before merging.
Validation warnings now stored in state object

This will allow for additional processing before actually triggering the
warnings. For the sake of this commit, though, we just keep with existing
functionality.
Warning no longer issued when overriding weak method appearing later in dfn obj
Began implementing virtual trait methods

These require special treatment with proxying.
Simplified ClassBuilder.buildMembers params

This cuts down on the excessive parameter length and opens up room for
additional metadata generation. Some slight foreshadowing here.
Added virtual members to class metadata

There does not seem to be tests for any of the metadata at present; they are
implicitly tested through various implementations that make use of them.
This will also be the case here ("will"---in coming commits), but needs to
change.

The upcoming reflection implementation would be an excellent time to do so.