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