[v18.x] deps: V8: cherry-pick d15d49b09dc7

Original commit message:

Make bitfields only as wide as necessary for enums

clang now complains when a BitField for an enum is too wide.
We could suppress this, but it seems kind of useful from an
uninformed distance, so I made a few bitfields smaller instead.

(For AddressingMode, since its size is target-dependent, I added
an explicit underlying type to the enum instead, which suppresses
the diag on a per-enum basis.)

This is without any understanding of the code I'm touching.
Especially the change in v8-internal.h feels a bit risky to me.

Bug: chromium:1348574
Change-Id: I73395de593045036b72dadf4e3147b5f7e13c958
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794708
Commit-Queue: Nico Weber <thakis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Auto-Submit: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82109}

Refs: https://github.com/v8/v8/commit/d15d49b09dc7aef9edcc4cf6a0cb2b77a0db203f Fixes: #52230 (closed)

(Note that this change is already in the baseline v8 of v20.x and newer, hence why this is a v18-only cherry-pick)

I carefully combed through this patch. The NodeState changes (include/v8-internal.h and src/handles/global-handles.cc) are not included, as the enum on v18.x is slightly larger (v18.x vs at time of v8 patch) so the current 3 bits is correct. And just to check: make jstest was able to catch this correctly.

I can confirm this patch fixes the build on Xcode 15.3.

We also have advance notice that this will be a hard error in LLVM Clang 19 (later this year) so -Wno-enum-constexpr-conversion would not have been a long-term fix:

The warning -Wenum-constexpr-conversion is now also enabled by default on system headers and macros. It will be turned into a hard (non-downgradable) error in the next Clang release.

https://releases.llvm.org/18.1.0/tools/clang/docs/ReleaseNotes.html