revise a decoder and encoder, being pure

[hannesm]

this is on the path to remove the functors from the main tar library.

while working on this, I encountered some issues in the reader already:

• if a zero block is read, the next block (if not another zero block, or a unmarshal error) is treat as a header directly (i.e. no pax/extended header disambiguation ongoing)
• the longname/longlink is ignored when there was a PerFileExtendedHeader -- since here after unmarshalling only a "fix_link_indicator" is called, but the longname/longlink arguments are not respected (I understand there's a todo "unclear how/if pax headers should interact with gnu extensions" -- and I don't know whether what this PR provides is what other tar implementations support as well)

happy to hear your feedback. if this PR is fine with you, I'm keen to use the decoder & encoder in the effectful layers (and remove the headerreader/headerwriter/other functors). WDYT?

[hannesm]

For reviewing purposes and testing purposes, I adjusted the list in parse_test to use the provided decoder, and their tests are passing :)

[hannesm]

This PR proposes a new API, and is ready for review. Tests are passing, missing bits are Tar_gz and the eio code. A thorough review of the functionality deployed in Tar_unix / Tar_lwt_unix would be great. Certainly there are missing bits and pieces (in extract / header_of_file / ..) we can fill in over time.

//cc @MisterDA @reynir who worked on the code (including removing Archive), and who may have ideas about users of the modules and whether these can be (easily) converted to this new API.

[reynir]

Overall I'm happy with the Tar changes. There is a thing about PAX headers in Tar.Header.make I'm not happy about but that was there before this change.

For Tar_unix I have some concerns about safety, potentially confusing names and unclear semantics of filtering. But I like how the usage of Tar looks like!