[arm64] Fix a stale todo and reorder opcodes

The todo is "fixed", in that we found the root cause, and recent
refactorings have given us more breathing space in the number of
opcodes, and also a static_assert was added to give a clearer error
message.

Bug: v8:10930
Change-Id: Ied47bf6a61a2bc70949c45f9d00d714b313a5192
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2469157Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70511}

src/compiler/backend/arm64/instruction-codes-arm64.h

@@ -371,6 +371,8 @@ namespace compiler {
   V(Arm64S128Load16x4U)                     \
   V(Arm64S128Load32x2S)                     \
   V(Arm64S128Load32x2U)                     \
+  V(Arm64S128LoadMem32Zero)                 \
+  V(Arm64S128LoadMem64Zero)                 \
   V(Arm64Word64AtomicLoadUint8)             \
   V(Arm64Word64AtomicLoadUint16)            \
   V(Arm64Word64AtomicLoadUint32)            \
@@ -406,11 +408,7 @@ namespace compiler {
   V(Arm64Word64AtomicCompareExchangeUint8)  \
   V(Arm64Word64AtomicCompareExchangeUint16) \
   V(Arm64Word64AtomicCompareExchangeUint32) \
-  V(Arm64Word64AtomicCompareExchangeUint64) \
-  V(Arm64S128LoadMem32Zero)                 \
-  V(Arm64S128LoadMem64Zero)
-// TODO(v8:10930) Adding new codes before these atomic instructions causes a
-// mksnapshot error.
+  V(Arm64Word64AtomicCompareExchangeUint64)
 
 // Addressing modes represent the "shape" of inputs to an instruction.
 // Many instructions support multiple addressing modes. Addressing modes