Add Optional 128-bit Integer Support to C++ Runtime

[AaronWebster]

Adds optional support for 128-bit UInt and Int fields (65–128 bits) to the C++ backend and runtime, using the compiler's native __int128_t / __uint128_t where available.

What this does

• prelude.emb: UInt and Int now permit static sizes up to 128 bits (previously 64).
• The runtime detects 128-bit support via EMBOSS_HAS_INT128 (derived from __SIZEOF_INT128__). When it is unavailable, fields wider than 64 bits fail to compile, exactly as before.
• The concrete 128-bit type is supplied through the EMBOSS_INT128_T / EMBOSS_UINT128_T macros, which a client may override (e.g. to a library 128-bit type) before including the runtime.
• LeastWidthInteger, BitBlock, MemoryAccessor, and ByteSwap are extended to 128 bits. Reads and writes work for full-width, non-full-width (e.g. 72/96-bit), little- and big-endian, arrays, and the text format.

Scope / limitations

• Anonymous bits types remain limited to 64 bits (widening them would require further work in OffsetBitBlock and the constraints checker).
• 128-bit support requires a platform/compiler with __int128 (64-bit GCC/Clang). 32-bit targets and MSVC are unaffected and continue to reject >64-bit fields at compile time.

Testing

• Runtime unit tests for ByteSwap, MaskToNBits, IsPowerOfTwo, LeastWidthInteger, MemoryAccessor (LE/BE, non-full-width), and UIntView / IntView read/write/sign-extension at 128 bits.
• Generated-code integration test (int128_sizes.emb) covering little-/big-endian structs, arrays, min/max, CopyFrom, out-of-range rejection, and text round-trips.

Changes since the previous review

This revision rebases onto current master and fixes correctness issues in the write/validation path that the earlier version did not handle:

• Range-check truncation. UIntView / IntView::CouldWriteValue compared the candidate value against the field bounds after casting it to uint64_t / int64_t. With a 128-bit ValueType this truncated the value, so an out-of-range value for a 65–127-bit field was accepted, and TryToWrite then aborted (or silently truncated) instead of returning false. The comparison is now done in the widest supported integer type.
• is_signed vs __int128. std::is_signed<__int128_t> is false under a strict -std=c++NN, so the signed lower-bound check (and negative-value text parsing) was compiled out for 128-bit signed fields. Signedness is now determined via std::numeric_limits<>::is_signed, consistent with how these methods are enabled.
• Reverted two unrelated whitespace-only changes flagged in the earlier review, defined the 128-bit ByteSwap in terms of EMBOSS_UINT128_T for override consistency, and sorted the testdata/BUILD entry.

[AaronWebster]

@jasongraffius Ready for another look

[robrussell]

The docs at https://github.com/google/emboss/blob/master/doc/language-reference.md#uint still say max size of Int and UInt are both 64 bits.

The different limit for the size of anonymous bit fields should be mentioned at https://github.com/google/emboss/blob/master/doc/language-reference.md#anonymous-bits .

[robrussell]

It looks like there's a place where a check for this this could be included at

emboss/compiler/front_end/constraints.py

Line 704 in b9f89e3

if in_attribute and in_attribute.name.text == attributes.STATIC_REQUIREMENTS:

but I'm not sure constraints.py would have enough information to know whether the platform supports 128-bit integers.

[robrussell]

I'm a little confused about this (including the previously existing implementation)
If kBits is 64 then this is

using Unsigned = typename LeastWidthInteger<65>::Unsigned;

Is this using just never applicable because the specializations for 64, 32, 16, and 8 always apply? Or is there something else I'm missing?