anlz: Use binrw instead of nom to parse ANLZ*.DAT files

[Holzhaus]

Closes #46.

[Swiftb0y]

Could you add a short explanation for each Unknown why that couldn't be removed?

[Holzhaus]

04b987f

[Holzhaus]

Without this, we wouldn't be able to parse *.2EX files. See #9.

[Swiftb0y]

note that exposing the Vec publicly mutably means that the beats.len() == len_beats invariant can be violated. binrw currently does not have a way to fix these up easily. see the issue where this is discussed in the context of binrw::FilePtr: jam1garner/binrw#4

[Holzhaus]

note that exposing the Vec publicly mutably means that the beats.len() == len_beats invariant can be violated.

Isn't that the case anyway even if the field was not pub? I could still crate an instance of the struct with mismatching len_beats and beats values by hand. The fix would be to make len_beats a temp field that isn't actually part of the struct and is only parsed for reading and automatically calculated from beats when writing.

[Swiftb0y]

Not sure, as mentioned in the FilePtr issue, a second pass could probably help with most of these issues. Another one could be to pass a reference to the field in the types args, but that is not supported either currently. Though both are on the v0.9.0 roadmap https://github.com/users/jam1garner/projects/1

Isn't that the case anyway even if the field was not pub? I could still crate an instance of the struct with mismatching len_beats and beats values by hand.

well if the type is public then yes, for this reason, I opted for an encapsulation approach in the DeviceSQLString implementation where the string is constructed correctly once and then should never be manipulated again, at least thats the plan, there are still some kinks to work out.

[Holzhaus]

Should be fixed with #51.