feat!: alternative API to allow Make(Int)

[favonia]

This breaking change is to allow code like these:

module S = Algaeff.State.Make (Int)
module R = Algaeff.Reader.Make (Int)
module S = Algaeff.Sequencer.Make (Int)
module U = Algaeff.UniqueID.Make (Int)

I don't feel the convenience is worth the trouble (which includes manually adding version upper bounds to released forester/asai/yuujinchou), but also why not. I am on the fence about this PR.

[jonsterling]

I think this is a good convenience...

[jonsterling]

But can we try to coordinate the releases of (e.g.) all these packages, including forester? Maybe we delay this until we are ready to do it all at once? Currently forester doesn't have any upper bounds, but this means that it is easy to break it from another package. This might have been a mistake on my part 😆

[favonia]

@jonsterling I don't get the benefit of coordination---no matter a release is delayed or not, we should update what's already in the OPAM repository with upper bounds, and with all upper bounds in the OPAM repository in place, I don't feel anything could (easily) go wrong? The next release of algaeff will be 2.0.0 due to the breaking change, so you can already add < 2.0.0 now before you use the new algaeff, and for this, maybe it's better to put algaeff 2.0.0 in OPAM first?

On the other hand, I'm of course not against coordination, though I'm not sure how to achieve that (I treat opam publish as a blackbox so that I'm not editing OPAM files directly). The other option is to use Algaeff2 just like QCheck2, but I prefer not to do this when it's still possible to manually update every package using algaeff.

[favonia]

My imagined plan:

1. Release the new algeaff as 2.0.0 AND add upper bounds to yuujinchou, asai, and forester in OPAM. This should keep everything working.
2. Release new yuujinchou 5.2.0 and asai 0.3.0 that use algaeff 2.0.0.
3. Release new forester

[favonia]

But maybe we should merge this PR and continue this discussion in a different issue...