Some of the methods in {WasmCodeAllocator} can be called either without
holding the lock, or while already holding it. In order to support both
situations, we used a {RecursiveMutex} so far.
This CL refactors this to be a simple {Mutex} again, and passes a
{WasmCodeAllocator::OptionalLock} object which stores whether the lock
is already held or not.
Note that getting the lock twice fails immediately in debug builds,
while forgetting to get the lock might only fail on TSan.

The alternative would be to duplicate all methods, having one variant
that expects that the lock is held and one that assume that it's
unlocked. It would be multiple methods though to duplicate across both
{NativeModule} and {WasmCodeAllocator}, hence I went for the
{OptionalLock} instead.

Bug: v8:9477

R=mstarzinger@chromium.org

Change-Id: I4e32286cdb93385ac655d408191b330efdd7ad66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825338
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64137}