Bug 902718 - Defer XPCOM release from the XBL compilation scope finalizer. r=mccr8

Apparently the current setup is incidentally safe, but far from kosher.
Bug 902718 - Add a mechanism to assert that the stack-top cx is an XBL compilation scope. r=bz
Bug 902718 - Stop taking an nsIScriptContext in XBL serialization routines. r=bz
Bug 902718 - Rip out nsIScriptContext from the lion's share of XBL code. r=bz

This kind of has to be done all at once. The primary correctness concern here is
making sure that we continue to operate in the correct compartment. So the basic
strategy here is as follows.

For most anything that previously took a script context, we remove the parameter
entirely and assert that the stack-top cx is in the compartment of the
compilation scope. We then bubble this up through all the callers until we hit
a caller that finds the scx via some means other than its parameter list. At
these points, we push the scx, making it stack-top.

This puts us in a good position to switch wholesale to the SafeJSContext in
subsequent patches.
Bug 902718 - Fix up nsXBLDocGlobalObject::GetGlobalJSObject() to force lazy global creation. r=bz

Currently we always pull the global off the nsIScriptContext, and trigger
a call to EnsureScriptEnvironment in the GetContext() call. So as we move away
from nsIScriptContext, let's make sure that GetGlobalJSObject continues to work
correctly.
Bug 902718 - Use the SafeJSContext for XBL serialization and deserialization. r=bz
Bug 902718 - Use the SafeJSContext for prototype member compilation. r=bz
Bug 902718 - Stop using nsIScriptGlobalObjectOwner to grab the compilation global. r=bz
Bug 902718 - Remove nsIScriptGlobalObjectOwner from XBL. r=bz
Bug 902718 - Stop using nsIScriptContext for XBL compilation. r=bz,mccr8
Bug 902718 - Fold EnsureScriptEnvironment into GetCompilationGlobal. r=bz