Threading JS for DOM Windows without making DOM threadsafe.

requirements:
We must not break the DOM0 invariant of "run to completion"

rules:
1. each top level content window created by the user gets its own js thread.
Caveat: just because such a thread is promised doesn't mean we actually have to have it. Call this an accounting thing.
- Tabs are top level content windows.
2. if a window is opened by another window, it doesn't get a new thread.
3. if a window doesn't have its own thread but is navigated by the
user to a new domain (breaking document.domain trust w/ window.opener), or if
the window.opener link is broken, the top level content window gets its own
thread
4. while the thread assigned to a "window" is running, no other js
can be dispatched for it (how this is handled should just magically work, but
,..)

5.  while js is running in a top level content window, no dom events
will be dispatched to or from any content within the top level window
6. any creature that tries to interact with any content window which is
in the state described by 5 will  be handled as if javascript is disabled
7. right clicking or dragging links from windows in the state described
by 5 is allowed because it's handled ...
by the chrome window or some other thing which is not the content window
8. javascript: urls share the execution thread with all other js content for the same top level content window.

9. all access from js to dom is via sync proxies.



random notes:
* i'm actually thinking of real threads
* the only reason for the caveat of 1 is that i don't want to guarantee 100
treal threads for 100 tabs
basically each top level dom content area has a pointer to a nsIThread
- if that pointer is null, then it would have to ask for one if it needed to
run js
- that's the caveat from 1
* if a window is sharing js w/ another window, then they share the thread
pointer (each having a reference)

* basically, no content js would ever run on the main thread

* yes it's a huge penalty eventually when we get around to proxying requests
for dom stuff

* it's something i'm willing to consider
* it doesn't involve making any of dom threadsafe

== why is it a huge penalty?
* basically any access to any dom bit will have to be proxied (sync) to
the main thread

== why not put critical sections around all the DOM code
 "all the dom code"

== Doesn't it go through a central "get_props" etc?
== bracketing 5 or 6 functions should be pretty easy
unfortunately the way xpcdom works
none  of the dom objects are threadsafe
and accessing a dom object involves an addref, and usually at least 1 qi if
you've never met the object before
that means each dom object has to be threadsafe

which means ... something

and this is where the dom owners start complaining

== The proxying thing isn't a trivial solution either, though
 actually, it should be trivial to implement
 we already have classinfo for dom objects
 and proxies can take adavcantage of that