The layout test that caused this revert was fixed with:
https://crrev.com/c/1627386

Original change's description:
> [array] Move Array#sort pre-processing to Torque
>
> This CL removes the "PrepareElementsForSort" runtime function, and
> replaces it with a simpler version in Torque. The biggest difference
> is that certain sparse configurations no longer have a fast-path.
>
> The Torque pre-processing step replaces the existing Torque mechanism that
> copied already pre-processed elements into the "work" FixedArray. The Torque
> compacting works as follows:
> - Iterate all elements from 0 to {length}
> - If the element is the hole: Do nothing.
> - If the element is "undefined": Increment undefined counter.
> - In all other cases, push the element into the "work" FixedArray.
>
> Then the "work" FixedArray is sorted as before. Writing the elements from
> the "work" array back into the receiver, after sorting, has three steps:
> 1. Copy the sorted elements from the "work" FixedArray to the receiver.
> 2. Add previously counted number of "undefined" to the receiver.
> 3. Depending on the backing store either delete properties or
> set them to the Hole up to {length}.
>
> Bug: v8:8714
> Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61812}

This removes dead and obsolete support for batch-saved register from the
safepoint table. We no longer spill the entire register window (either
double or general-purpose) from optimized code. All spills happen as
part of the normal spill-slots on the stack by now.

Original change's description:
> [array] Move Array#sort pre-processing to Torque
>
> This CL removes the "PrepareElementsForSort" runtime function, and
> replaces it with a simpler version in Torque. The biggest difference
> is that certain sparse configurations no longer have a fast-path.
>
> The Torque pre-processing step replaces the existing Torque mechanism that
> copied already pre-processed elements into the "work" FixedArray. The Torque
> compacting works as follows:
> - Iterate all elements from 0 to {length}
> - If the element is the hole: Do nothing.
> - If the element is "undefined": Increment undefined counter.
> - In all other cases, push the element into the "work" FixedArray.
>
> Then the "work" FixedArray is sorted as before. Writing the elements from
> the "work" array back into the receiver, after sorting, has three steps:
> 1. Copy the sorted elements from the "work" FixedArray to the receiver.
> 2. Add previously counted number of "undefined" to the receiver.
> 3. Depending on the backing store either delete properties or
> set them to the Hole up to {length}.
>
> Bug: v8:8714
> Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61812}

This CL removes the "PrepareElementsForSort" runtime function, and
replaces it with a simpler version in Torque. The biggest difference
is that certain sparse configurations no longer have a fast-path.

The Torque pre-processing step replaces the existing Torque mechanism that
copied already pre-processed elements into the "work" FixedArray. The Torque
compacting works as follows:
- Iterate all elements from 0 to {length}
- If the element is the hole: Do nothing.
- If the element is "undefined": Increment undefined counter.
- In all other cases, push the element into the "work" FixedArray.

Then the "work" FixedArray is sorted as before. Writing the elements from
the "work" array back into the receiver, after sorting, has three steps:
1. Copy the sorted elements from the "work" FixedArray to the receiver.
2. Add previously counted number of "undefined" to the receiver.
3. Depending on the backing store either delete properties or
set them to the Hole up to {length}.

Now with an ASAN-container-overflow false positive workaround:
Somehow ASAN was unhappy about a simple
std::vector<std::string>::push_back.
Increasing the std::vector capacity before doing the push_back
strangely fixes the problem.

On Android, we mmap the .so directly from the APK, therefore the file offset
in this case refers to the offset of the .so in the APK, not the offset in
the .so file itself. As such, moving the start position of the library based
on this gives incorrect results when later symbolizing the addresses based on
the .so.

Rework limit computation:
- Model controller as static classes based on traits.
- Compute growing factors for both controllers and pick the
larger growing factor for both controllers.
- Factor out limit computation in its own function.

Split the JSONConsumer into a base case and subclass so that we can
implement different consumers without needing to repeat the code that
deals with the finished semaphore and endpoint setters/getters.

This makes it possible to add a test consumer that just holds the trace
events in memory in a later CL.

This CL re-uses the existing perfetto-consumer.h file to some extent,
but it was accidentally leftover from a previous CL where we stopped
using it and switched to the JSON consumer instead.

Since we currently require at least 1 MB of code to be potentially
dead, we will never trigger GC for small modules.
This CL lowers the threshold to 64 kB (plus 10% of committed code
space), which has basically no effect on large modules, but ensures
that we also run GCs on small modules.

The python script allows to inject hints into a Wasm module. Hints are
injected into a newly created custom section named "compilationHints"
that is used by the compiler to determine its compilation strategy. The
section is placed after the functions section and before the code
section.

The {new_potentially_dead_code_size_} counter is used to decide when to
trigger the next GC. Without resetting, we will trigger lots of GCs
once the counter hits the limit, see
"V8.WasmModuleNumberOfCodeGCsTriggered" counter.

The previous logic published whenever a TurboFan function was
*finished*. Since we compile big functions first, the first TurboFan
compilation can take quite some time, and we will only publish
previously compiled Liftoff functions once that first TurboFan
compilation is done.
This CL changes that logic to publish all previous results *before*
starting a TurboFan compilation.

Split out embedded file writers for AIX, Windows, and macOS. These are
no longer selected by compile-time defines (e.g. V8_OS_WIN,
V8_TARGET_ARCH_X64) but by --target-os and --target-arch runtime
flags.

Introduce a single point to emit CodeCreateEvents for all builtins in
Isolate::Init. At this location, we cover both the case of builtin generation
(e.g. in mksnapshot) and deserialized builtins (in standard builds),
whereas previously we only emitted events post-builtin-generation.

In order to preserve behavior for bytecode handler events, pack the bytecode
and operand scale into our existing builtin metadata table.