Bug 1052089 - Sprinkle some assert against using nsContentUtils too early. r=billm

And earlier version of these patches called nsContentUtils::GetSystemPrincipal()
too early, which returned null, and caused xpc::CreateSandboxObject to create
an nsNullPrincipal. Let's avoid having that happen again.
Bug 1052089 - Add a System Principal accessor to nsXPConnect and use it in Sandbox creation. r=billm

nsContentUtils isn't ready by this point.
Bug 1052089 - Stop using a contractid to create a null principal during sandbox creation. r=billm

This causes problems when used too early in startup.
Bug 1052089 - Don't require the cx to be in a compartment during sandbox creation. r=billm
Bug 1052089 - Don't fuss around with remote-XUL XBL-scope special cases for sandboxes. r=billm
Bug 1052089 - Make the junk scope invisible to the debugger and Components-less. r=billm

This prevents the JS engine from trying to fire off debugger notifications and
do other complicated things when we create this thing early in startup in the
upcoming patches.
Bug 1052089 - Infallibly init singleton scopes in the XPCJSRuntime constructor. r=billm

We've had some problems with GetJunkScope returning null and causing crashes in
the past, but I'm now pretty convinced that just null-checking it isn't the
answer. Rather than creating it lazily, we should create it at a defined point
in startup. Any problems will then be much more reproducible, and we can track
them down and fix them.
Bug 1052089 - Rename JunkScope to PrivilegedJunkScope and remove fallibility of singleton scope access. r=billm

These two things ended up getting mushed together in my tree.
Bug 1052089 - Swap out the SafeJSContextGlobal for the new UnprivilegedJunkScope. r=billm