This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.

This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.

Additionally, this CL implements the proper base + offset initialization
behavior for tables.

R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316

Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}

This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.

BUG=v8:5409

Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}

This reverts commit 1eb1dfab.

The original compilation separation change avoided associating a heap
for the wasm instance if memory was not provided, nor needed. The
grow memory CL assumed the old behavior, where a memory buffer was
always present, but may have had a zero size.

The 2CLS  landed shortly after one another. We decided to treat the
grow memory as the race condition winner, so this CL here re-lands
compilation separation, plus adjusts grow memory to deal with
the undefined mem buffer.

BUG=

Review-Url: https://codereview.chromium.org/2102193003
Cr-Commit-Position: refs/heads/master@{#37352}

This reverts commit 0c7ee927.

BUG=

Review-Url: https://codereview.chromium.org/2103983003
Cr-Commit-Position: refs/heads/master@{#37351}

Support for serializing/deserializing the compiled wasm module.

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling
debugging scenarios. This imposes a ~20% penalty on the memory
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information
necessary to support instantiation.

Given how whatever we need to persist must be serializable, the CL
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer.

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

BUG=

Review-Url: https://codereview.chromium.org/2094563002
Cr-Commit-Position: refs/heads/master@{#37348}

R=bmeurer@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#28191}