Relax the BJData fuzzer's round-trip check from byte-exact to value-exact

Fixing #5398 lets to_bjdata() proceed past the object it used to reject,
which exposed a pre-existing, unrelated round-trip quirk to the fuzzer:
a binary_t value serialized through the non-optimized ("$U#"-less)
array encoding is parsed back as a plain array of numbers, since
from_bjdata() has no way to tell "array of uint8 numbers" apart from
"array of bytes" without that optimized header. Re-serializing that
plain array then goes through the generic smallest-type writer, which
- unrelated to this PR, and long predating it - prefers the 'i' (int8)
marker over 'U' (uint8) for values that fit both, so the re-encoded
bytes can differ from the original even though both decode to the same
value.

This is not introduced by the #5398 fix; the same divergence reproduces
from a bare json::binary_t value with no _ArrayType_ annotation
involved at all, on the commit immediately preceding it. A general fix
would mean changing the shared UBJSON/BJData smallest-type selection
that hundreds of existing tests pin to 'i' for small positive
integers, which is out of scope and too risky for this PR.

Update fuzzer-parse_bjdata.cpp's round-trip assertions to check that
re-serializing is value-stable (from_bjdata(to_bjdata(j)) == j) rather
than byte-exact, matching the guarantee BJData actually provides, and
add a regression test in unit-bjdata.cpp using the exact OSS-Fuzz input
that documents the behavior.

Signed-off-by: Niels Lohmann <mail@nlohmann.me>

tests/src/fuzzer-parse_bjdata.cpp

@@ -21,6 +21,18 @@ array data, it performs the following steps:
 - j4 = from_bjdata(vec3)
 - assert(j1 == j4)
 
+Re-serializing j2/j3/j4 with the same use_size/use_type settings is checked
+for value-stability rather than byte-exact stability: from_bjdata(to_bjdata(j2))
+must equal j2 (and likewise for j3, j4). Byte-exact stability does not hold in
+general, because a BJData value can lose type fidelity across a round trip
+(e.g. a binary_t value serialized without the optimized "$U#" array header is
+parsed back as a plain array of numbers, see #5398 and the discussion on
+PR #5494) - the numeric value is preserved, but the writer's smallest-type
+selection for the now-plain numbers may legitimately pick a different, but
+equally valid, single-byte type marker than the dedicated binary-data writer
+would have. Both encodings are valid BJData and both decode to the same
+value, so this is not treated as a round-trip failure here.
+
 The provided function `LLVMFuzzerTestOneInput` can be used in different fuzzer
 drivers.
 */
@@ -56,10 +68,11 @@ extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size)
             json const j3 = json::from_bjdata(vec3);
             json const j4 = json::from_bjdata(vec4);
 
-            // serializations must match
-            assert(json::to_bjdata(j2, false, false) == vec2);
-            assert(json::to_bjdata(j3, true, false) == vec3);
-            assert(json::to_bjdata(j4, true, true) == vec4);
+            // re-serializing must be value-stable (see the note above on why
+            // byte-exact stability is not guaranteed in general)
+            assert(json::from_bjdata(json::to_bjdata(j2, false, false)) == j2);
+            assert(json::from_bjdata(json::to_bjdata(j3, true, false)) == j3);
+            assert(json::from_bjdata(json::to_bjdata(j4, true, true)) == j4);
         }
         catch (const json::parse_error&)
         {