[oilpan]: fix deadlock when leaving a safepoint and sweeping.

In the case where a thread takes a lock/mutex within a safepoint scope and leaves the safepoint with the lock held we risk deadlocking if the same thread takes the same lock in a destructor. The reason is that if another thread did a GC while the first thread was in the safepoint the sweep done by the first thread will potentially call a destructor which could then take the same lock. Since the WTF:Mutex is not recursive/reentrant the thread will deadlock on itself.
This change fixes this by introducing a RecursiveMutex which allows a thread to take a lock it is already holding. Interestingly the Windows WTF:Mutex is currently reentrant wrt. the lock() method, but not wrt. tryLock() since tryLock mimics the behavior of the pthread_mutex by keeping a recursion count. To deal with this I introduce a separate tryLock method for the Mutex and the RecursiveMutex that behaves different on windows. On pthreads (Linux/Mac) the tryLock method is identical since it changes behavior depending on how the mutex is created.

I have added a test which demonstrates the dead-lock issue.

R=ager@chromium.org, erik.corry@gmail.com, haraken@chromium.org, oilpan-reviews@chromium.org, sigbjornf@opera.com, tkent@chromium.org, zerny@chromium.org
BUG=

Review URL: https://codereview.chromium.org/415083002

git-svn-id: svn://svn.chromium.org/blink/trunk@178928 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Handle a terminating context in messageHandlerinWorker().

If execution is terminated while constructing the ErrorEvent representing
the incoming v8::Message, do not attempt to report the exception.

R=haraken@chromium.org
BUG=393273

Review URL: https://codereview.chromium.org/405933002

git-svn-id: svn://svn.chromium.org/blink/trunk@178929 bbb929c8-8fbe-4397-9dbb-9b2b20218538