Bug 761695 - Fix inaccurate commenting. v1

The .wrappedJSObject property only exists when the Xray wrapper subsumes the wrappee.
Bug 761695 - Simplify XPCWN Xray holder creation. v1

The major semantic change here is that we parent holders directly to their
global. This should be fine.
Bug 761695 - Stop stashing a raw WN pointer in XPCWN Xray holders. v1

We might as well do this dynamically, which simplifies the code. Note that we
could avoid the reserved slot by parenting the holder to the wrapper. But the
JS parent API is deprecated, and we need to move away from it to reserved slots
anyhow. We might as well start here, with the added advantage that parenting
to the global makes us consistent with the other Xray types.
Bug 761695 - Make Xray traits inherit from a common superclass and give them a singleton instance. v1

There's some code that can be shared between different Xray traits, but can't
(yet) be hoisted into XrayWrapper, because it needs to be callable from outside
XrayWrapper where we don't have the appropriate template parameters. Moreover,
this code benefits from virtual function specialization. The use case here is
illuminated in the next patch.

For the moment, we skip converting the bulk of the traits calls to virtual
methods, because they're working just fine.
Bug 761695 - Hoist getInnerObject into XrayTraits. v1

The only special handling here with wrapped natives is to make sure that we
bypass outer windows. But we can do this with js::UnwrapObject.
Bug 761695 - Rename getInnerObject to getTargetObject. v1

The current name potentially implies that the object returned is an inner
object in the JS sense, which isn't true. Really we just want the thing
we're Xraying to.
Bug 761695 - Hoist call and construct traps into Traits, since the current implementations are XPCWN-specific. v1
Bug 761695 - Get the WN directly from the wrapper. v1

All this indirection was getting seriously mucky. This, incidentally, means that
the XPCWN holder no longer needs a reserved slot pointing to the WN.
Bug 761695 - Unify holder creation and access. v1

With this patch, all holders are created lazily. There are two common accessors,
getHolder() and ensureHolder(). The former returns null if no holder exists, the
latter lazily creates the holder if it doesn't exist. It does this by calling into
a virtual trap on XrayTraits, which lets the appropriate Xray type do its thing.
Bug 761695 - Move Xray expando infrastructure further down in the file. v1

Just cut/paste. No code changes.
Bug 761695 - Hoist Xray identification machinery into XrayWrapper, and use it for trait identification. v1

We don't currently have a good way of selecting the traits used by a given Xray
wrapper. This lets us do that.

Note: We add a call to js::UnwrapObject to GetXrayType while hoisting it. When
it was used only in WrapperFactory, this was unnecessary, because |obj| was
always unwrapped. But for our new purposes, it might not be. Aside from that,
there are no changes to the function.
Bug 761695 - Hoist expando infrastructure into XrayTraits. v1

It's still WN-only, now we can move the WN-only bits into virtual traps.

Note that the new-binding reparenting code will need to have a call to
CloneExpandoChain.
Bug 761695 - Make expando chain getting/setting a virtual trap. v1
Bug 761695 - Move wrapper preservation stuff into a virtual trap. v1

I'm not sure this stuff is correct for non-WN objects. Hopefully that will
come out in review.

Anyway, with this change, the expando infrastructure in XrayTraits is now
fully generic and non-WN-specific. To make things work for other objects,
we now need to implement the virtual traps and hoist the code that calls the
expando machinery out of XPCWrappedNativeXrayTraits.
Bug 761695 - Implement expando traps for ProxyXrayTraits DOMXrayTraits. v1

For new DOM proxies, we could probably use the Xray expando machinery for the
regular expando object as well, and free up one of the reserved slots. That's
more than I want to bite off for the moment, though.

I also decided not to block on bug 760095 and just kick the problem of globals
with new binding down the road a little bit.
Bug 761695 - Factor common code into XrayTraits resolveOwnProperty implementation. v1

Soon, we'll add code here to check the expando object. This needs to be non-static
and virtual so that we have access to the appropriate singleton in
XrayTraits::resolveOwnProperty (otherwise we can't call getExpandoObject).
Bug 761695 - Hoist expando-checking (but not expando-creating) operations into common code. v1

We do this for delete_, enumerateNames, and resolveOwnProperty. This doesn't change
existing behavior, because for ProxyXrayTraits and DOMXrayTraits the expando object
will (currently) always be null.
Bug 761695 - Put Proxy and DOM expandos on the expando object, rather than the holder. v1

With this change, expando sharing is now implemented for all Xrays. \o/

Also, because of my *ahem* forward-thinking test design for the initial WN
implementation, the test coverage here is alrady ready to go!