A type t, equal, show and pp

[Leonidas-from-XIV]

Closes #71.

I think most of it is pretty obvious except for how equality on Assoc would be handled. Since keys can repeat in that association list, I implemented it in a way where same keys must have the same value (thus a custom mem-like function). It is not optimal, since that comparison is O(n^2), but I decided to submit it anyway to have a discussion on whether these semantics are what we want to have to begin with. There are some obvious optimizations but let's take this as starting point.

[Leonidas-from-XIV]

The latest commit is green except for a single macOS build which failed for random reasons. Rerunning that particular build it should help but I can't trigger a rebuild. Maybe @pmetzger can?

[NathanReb]

Thanks for that!

I restarted the failed job and I'll have a look ASAP.

[Leonidas-from-XIV]

Looks like it worked this time. Builds on macOS are a bit tiring because they take a long time to start and have a tendency of randomly failing a bit too often.

I haven't included compare because I don't have too much use for it personally, but if there is interest I can also add that in a later PR, by the magic of "stealing whatever ppx_deriving generates".

[Leonidas-from-XIV]

While working on another PR I realized there is sort which might actually be the better solution to determining whether two `Assocs are equivalent, especially since the sort logic exists and due to its existence is the "canonical" way of ordering keys in an `Assoc. Let me know what you think.

[NathanReb]

No problem about compare, we can add that later if anyone expresses a need for it, that's already a huge improvement as it is.

I agree sorting the assoc lists based on the key is the way to go here. It will make the code easier to read and will yield a better average time complexity. If performances become an issue even then we can think about improving it but I doubt it'll come to this.
There will be undefined behavior with objects having multiple occurrences of the same key but the current implementation will also yield some odd results in those cases and I don't think we should bother treating those.

What would you think about adding unit tests for those? Especially for equal since it has some custom logic that one might inadvertently break.
I think that might be the right time to add some. Your help on this is already much appreciated and if you do not wish to bother writing tests I'll just take care of it later.

[Leonidas-from-XIV]

I will add unit tests to it (and actually it is way nicer now, since I have an equality and a pretty printer that I can use in the tests), but since that takes a bit of time I submitted the other changes that you requested since they were quick to do.

[Leonidas-from-XIV]

After adding the deprecation annotation I had to change all occurrences of json to t to not trigger deprecation warnings ourselves.

[NathanReb]

I added a few suggestions, let me know what you think!

[Leonidas-from-XIV]

I added some unit tests, though I didn't bother to test the non-standard extensions to JSON. It uses alcotest which I added as a test-only dependency.

I think the CI scripts will run the tests automatically, though we might possibly disable them on all but one build because running the tests takes a while because it rebuilds it with test dependencies.

[NathanReb]

Thanks for your time and effort on this, it's much appreciated!

About the CI, I'm not sure this will have significant impact on the already insanely long CI runs. I think dropping CI builds for versions older than 4.04, even maybe 4.05 would make sense.

The osx builds are also way too long, I'll look into this but I might only test osx with the latest ocaml version for instance.

Anyway, I digress, tyvm, merging!