These have unknown instance objects, and were tripping up our parsing. I
don't know what these are yet, but I added them anyway.
I also made sure that the parser doesn't return None for technically
valid but empty LGB files.
I broke this when changing a split to split_once I think, and it stayed
broken longer than it ever should have. To stop that from happening
again, more tests are added to catch this.
This is a bit of an awkward API, because we have to manually keep the
CRC list up-to-date when in other cases that's left up to consumers. I
added a comment about how to figure out this value.
As suspected - this was a little slow, and can be corroborated with
Hotspot. This is only a marginal increase in performance, it isn't huge
but still worth doing.
Apparently we were reading packed booleans wrong the whole time
(whoops!) They are packed into *bytes*, oops... That is fixed now, and I
also expanded write support for packed booleans. It makes the assumption
that the byte is always at the end of the row, but I think that's OK for
now.
I also added a good test-case for this, the PhysicsGroup EXD. It has a
lot of rows, and some packed booleans thrown in. The columns also have
out-of-order column definitions (as in, their offsets don't increase in
order.)
Now we can re-create OpeningSystemDefine, and is added as a new test
case to test reading/writing string columns. This was actually quite
fun, it turns out that they like aligning the data sections to a 4-byte
boundary for some reason.
Expanding upon the EXH tests of this same data, we can successfully
write it back (hence why it's testdata now!) A lot of the writing logic
is specific for this EXD, but it's a start.
I updated our dependencies like binrw to 0.15, which is pretty nice as
that means we no longer depend on Syn 1.x. I also finally upgraded to
bitflags 2.x, which doesn't really mean anything except we're on
better supported version.
Additionally, I removed some bitrotten code that no longer compiles.
This was mostly benchmark stuff, but since I don't actively keep track
of that I felt it was better to remove it. I can always add it back once
I'm ready to tackle that again.
Apparently X-Patch-Length is only for the base repository, and so isn't
a reliable indicator. But it's pretty simple to add them all together to
get a close number.
