trimmed release 18.0.1025.162
trimmed release 19.0.1084.52
trimmed release 20.0.1132.47
trimmed release 20.0.1132.57
trimmed release 21.0.1180.60
Disable the V8RecursionScope assertion

DRQS 34552506
This assertion makes it impossible to allow non-webkit related JavaScript run
in the same isolate as WebKit, without adding a MicrotaskSuppression guard,
which is impossible without a bunch of levelization hacks.

The only purpose of this assertion is to ensure that if the JavaScript modifies
the DOM, then the mutation events will be fired once the V8RecursionScope goes
out of scope.

In our case, we would construct a V8RecursionScope around an entire block of
code that manipulates the DOM, not at each function call site.  Therefore it
would be the responsibility of higher level code to ensure that they add
V8RecursionScope in the right places to cause mutation observer to do its work.
trimmed release 23.0.1271.97
trimmed release 24.0.1312.52
trimmed release 24.0.1312.56
trimmed release 25.0.1364.84
trimmed release 25.0.1364.152
trimmed release 26.0.1410.33
trimmed release 26.0.1410.43
trimmed release 27.0.1453.73
trimmed release 27.0.1453.94
Add the ability to build sandbox in a DLL module

TREQ 2526677

This change takes advantage of the existing 'SANDBOX_EXPORTS' behavior, with
the additional feature that the sandbox code can be linked into a DLL instead
of linking directly into the executable.

When spawning the target process, the initial token will be preserved after the
process is launched (but still in suspended mode).  At this point, the DLL
containing the sandbox code will be injected using a remote thread running
inside the target process, created from the broker process.  After this, the
initial token is closed and execution resumes as normal.

Also, the exported symbols are now obtained from 'SandboxModule' instead of
'MainModule'.  If the DLL was not injected, then 'SandboxModule' is treated
equivalent to 'MainModule'.
Don't inject dll if exe has sandbox linked in

If the target exe has sandbox.lib linked into it, then we don't need to inject
the dll.  Instead, we just use the exported symbols from the exe itself.
trimmed release 27.0.1453.110
Allow explicit destruction of singletons

Classes that implement SingletonBase (e.g. BrokerServicesBase) are
automatically deleted using Microsoft's '_onexit' CRT extension.

However, this causes issues when the sandbox is linked into a DLL, and the DLL
is implicitly loaded by the EXE.  In this case, the BrokerServicesBase object
is destroyed from the DLL CRT after WinMain has returned.

It seems like process handles are invalidated before that point, because the
TargetProcess destructor (which gets invoked from the job-thread) never returns
from waiting for the process to exit, even though the process has actually
exited.  It looks like the job-thread "disappears", because BrokerServiceBase
finishes waiting for it.  But it then crashes when calling FreeResources,
because it is trying to free a job that has been partially freed by the
job-thread (which just didn't get around to cleaning up after the free).

The simple solution to this problem is to expose a method that we can call
explicitly before returning from WinMain, which will cleanup all the
singletons.  This causes the BrokerServicesBase to wait for the job-thread to
complete successfully.
Merge branch 'feature/sandboxDLL' into feature/blpwtk2