Trait named staging object

This implements Trait("Foo"), analogous to Class("Foo"). This was intended
to have existed in the 0.2.0 release, but was overlooked.
Version bump 0.2.2-dev

Whoops! Meant to do this a lot sooner.
Trait API now exposed in combined source files

I missed this in the 0.2.0 release and did not notice in code I've been
writing using traits because the test cases are executed by Node. Sorry to
anyone who may have had trouble client-side.
Added isCompatible method to interfaces

There is a great amount of rationale in the test case added in this commit.
ClassBuilder.isInstanceOf now defers to type

This allows separation of concerns and makes the type system extensible. If
the type does not implement the necessary API, it falls back to using
instanceof.
Overriding vanilla prototype methods no longer errors

This is something that I've been aware of for quite some time, but never got
around to fixing; ease.js had stalled until it was revitalized by becoming a
GNU project.
Prototype supertype property proxy fix

This was a nasty bug that I discovered when working on a project at work
probably over a year ago. I had worked around it, but ease.js was largely
stalled at the time; with it revitalized by GNU, it's finally getting fixed.

See test case comments for more information.
Test case to protect agaist retval regressions when extending prototypes
Class#asPrototype support

This is an interop feature: allows using ease.js classes as part of a
prototype chain.
Began work on interop chapter of manual
Added section to manual on interoperable polymorphism
Vanilla ECMAScript interop patches

Now that ease.js is a GNU project, it has much broader reach than before.
Since its very existence is controversial, it would be wise (and polite) to
provide a means for others to integrate with libraries written using ease.js
without being forced to use ease.js themselves. Further, ease.js users
should be able to build off of the work of other libraries that do not use
ease.js.

This set of changes introduces a number of interoperability improvements,
documented in the new manual chapter ``Interoperability''. Since it is
documented in the manual, this commit message will not go into great detail;
I wish to only provide a summary.

Firstly, we now have the concept of interface compatibility; while ease.js
classes/etc must still conform to the existing interface requirements, the
rules are a bit more lax for other ECMAScript objects to permit
interoperability with type-checking ease.js code. For example:

  var I   = Interface( { foo: [ 'a' ] } ),
      obj = { foo: function( a ) {} };

  Class.isA( I, obj );  // true

This is also a powerful feature for implementing interfaces around existing
objects, as a preemptive interface check (rather than duck typing).

Prototypally extending ease.js classes is potentially problematic because
the constructor may perform argument validations (this is also an issue in
pure prototypal code). As a solution, all classes now have a static
`asPrototype` method, which defers constructor invocation, trusting that the
prototype constructor will do so itself.

Aside from a few bug fixes, there is also a more concise notation for
private members to allow prototypal developers to feel more at home when
using GNU ease.js: members prefixed with an underscore are now implicitly
private, which will satisfy the most common visibility use cases. I do
recognize that some (mostly in the Java community) use underscore *suffixes*
to denote private members, but I've noticed that this is relatively rare in
the JS community; I have therefore not included such a check, but will
consider it if many users request it.

There are many more ideas to come, but I hope that this will help to bridge
the gap between the prototypal and classical camps, allowing them to
cooperate with as little friction as possible.
Version bump 0.2.2-dev => 0.2.2
Subtypes of prototype subtypes now work correctly
Fix for subtypes of prototype subtypes

When extending a class that is a subtype of a prototype, it would clobber
___$$vis$$, yielding a useless class. See the test case for a detailed
description.
Trait virtual method proxies now set __length metadata

This fixes a bug that causesd virtual definitions with parameters on classes
that a trait is mixed into to fail, and prevented proper param length
validations in the reverse case.

See test case description for a less confusing description.