[pickles] Document Hlist

[Firobe]

Add considerable documentation to Hlist in the pickles lib, in a new MLI file.

Also renames Fst and Snd to Arg1 and Arg2, and removes Hlist_1, which is redundant with Hlist0.H1_1.

[mimoo]

At a glance this looks great o_O!! Two small questions:

• did you manage to build HTML documentation out of these files? I couldn't when I tried
• unrelated to this PR, but do you think this should live outside of pickles, as its own library or as part of a utility library?

[Firobe]

At a glance this looks great o_O!! Two small questions:

• did you manage to build HTML documentation out of these files? I couldn't when I tried

Yup! I had to build the whole documentation for the repo by running dune build @doc at the root. There are a number of errors but they can be ignored. I temporarily hosted a copy of the generated documentation here if you want to browse it.

• unrelated to this PR, but do you think this should live outside of pickles, as its own library or as part of a utility library?

I'd love to have a generic HList library living completely outside of Mina. However here Hlist is tightly tied to the other types in pickles_types, so I don't think it would be possible or desirable to completely isolate Hlists from this library. Furthermore there really are not a lot of situations where you would want to use these lists in general, so they won't be reused much anyway.

[mrmr1993]

This looks great to me! I've sprinkled a few nits, but this is already a huge improvement.

1 caveat: I suspect you didn't intend to update the snarky submodule 😁

[Firobe]

1 caveat: I suspect you didn't intend to update the snarky submodule 😁

Removed that nasty change from the commit 😅 Good work for noticing that

[mrmr1993]

Excellent!

[mrmr1993]

Submodule updates have slipped back in.

(Also, if you force push rather than adding new commits, I can't easily track what's changed between one review and the next, which is a pain.)

[Firobe]

Right, sorry. Force-pushed a last time to remove the submodule updates again. I like to keep a clean history but I guess I should rebase at the very end before merging instead of doing it continuously.

[mrmr1993]

I like to keep a clean history but I guess I should rebase at the very end before merging instead of doing it continuously.

We've been running with a policy of 'merge what was approved' and 'don't change branches out from under reviewers'. Our git history is a mess, but reviews and merges are way easier than they were before.