rough draft of the serialization runtime

[laura-a-n-n]

TODOs:

• go back and fix formatting to be more consistent, i accidentally allowed my ide to auto-format stuff.
• reorder functions to be in a more logical order
• implement many of the more specific write methods
• do a lot more testing

tested on one ksy file that only uses u1, u2, u4, and s2 for primitive data types.

used with a very rough draft of the compiler on the fork here: laura-a-n-n/kaitai_struct_compiler@serialization...laura-a-n-n:kaitai_struct_compiler:javascript-serializer

possible flaws / areas for improvement:

• write functions create a new DataView object each time. should we be using a shared DataView to do operations?

EDIT for the above task (08/17/2024):

My understanding is that this is not possible at the moment. My initial suspicion was that this was the way to go, especially due to the serial nature of the data, we don't have to worry about concurrency issues that arise when sharing a write buffer.

However, the main problem would be resizing the ArrayBuffer to varying byteLengths. This is completely possible, but it is a relatively new feature. Since the runtime is currently not transpiled with Babel and we'd like to target older browsers, I don't think is afforded to us.

So, I'll stick to creating a new ArrayBuffer and DataView for each write. I ask that reviewers take special note of this and verify my findings. I welcome any corrections or suggestions.

There's probably a better solution.

• zlib support / compression not implemented