Document how to handle unsigned 64-bit integers in Java
Java doesn't have a primitive unsigned 64-bit integer type - it only has `long`, which is *signed* 64-bit. When Kaitai Struct has to work with unsigned 64-bit integers (`u8`) in Java, it represents them as `long` by wrapping/casting them to signed. For example the unsigned value 18446744073709551615 is represented as the signed value -1 (these two values have the same bit representation, assuming two's complement for the signed value, as Java does). This avoids having to store `u8` values using `BigInteger`, which is less efficient and less convenient to use than `long`.

The [language specific notes for Java](https://doc.kaitai.io/lang_java.html#_primitive_type_mapping) only has one short sentence documenting this behavior:

> There are no support for unsigned integer types in Java. [...] KS tries to make up for that fact by using larger signed types where that’s possible and reasonable to do. Where it’s not possible (i.e. 64-bit unsigned integers — `u8`), KS would use signed long type.

I think this should be explained separately in a bit more detail, because the way `u8` values need to be handled is quite different from the smaller unsigned types and requires extra care from the programmer. Smaller unsigned integers can normally be used without extra precautions - the only unusual behavior is that they're represented as a type that's twice as large (e. g. `u2` becomes `int` because Java has no `unsigned short`), but this is rarely an issue.

In contrast, because `u8` values are represented as signed `long` using wraparound, such a value can't always be used like a normal `long`. Some operators still work correctly thanks to the two's complement representation (`==`, `+`, `-`, `~`, `&`, `|`, `<<`), but others have to be replaced with alternatives that treat the value as unsigned (`>>` becomes `>>>`, `/` becomes `Long.divideUnsigned`, etc.). Writing a literal unsigned `long` (for comparison or bit operations) may require using a hexadecimal literal, because the compiler doesn't allow decimal `long` literals that would overflow. Even just printing out the value requires using `Long.toUnsignedString` to get correct output, and many APIs don't support this kind of pseudo-unsigned `long` at all.

Because this isn't something the average Java programmer has to deal with normally, and because it's very easy to use a pseudo-unsigned `long` as a regular signed `long` by accident, this should be documented in more detail in the Java notes. A short example of how to correctly do simple arithmetic and bit operations with pseudo-unsigned `long`s would also be helpful perhaps.

For more info, see kaitai-io/kaitai_struct_compiler@dbda9b765e1c57f8e2e5dcfcf7d33dc7b1e8e48e, kaitai-io/kaitai_struct_compiler#212, and [`KaitaiStream.readU8be`](https://github.com/kaitai-io/kaitai_struct_java_runtime/blob/ea3abf89ee7745ac56c814202c4ddb26fc668e11/src/main/java/io/kaitai/struct/KaitaiStream.java#L135-L142).