feat: Relax the client/server coupling & Add support for API versioning

[erikmd]

Excerpt of the learnocaml_api.mli file:

(** Note about backward-compatibility:

The architecture of learn-ocaml merges the (client, server) components
in the same codebase, so it's easier to update both of them in one go.

But this tight coupling meant that a learn-ocaml-client version would
only be compatible with a single server version, hence a frequent but
annoying error "API version mismatch: client v._ and server v._".

So since learn-ocaml 0.13, a given client_version will try to be
compatible with as much server_version's as possible (>= 0.12 &
<= client_version).

To this aim, each [request] constructor is annotated with a version
constraint of type [Compat.t], see [supported_versions].

Regarding the inevitable extensions of the API:

- make sure one only adds constructors to this [request] type,
- and that their semantics does not change
  (or at least in a backward-compatible way;
   see PR https://github.com/ocaml-sf/learn-ocaml/pull/397
   for a counter-example)
- but if a given entrypoint would need to be removed,
  rather add a Compat.Upto (*<*) constraint.
 *)

To sum up this PR in a few items:

• It bumps the version to 0.13.0 (semver), instead of not 0.13 which seems not release-please compliant;
• (and for each upcoming release, a good practice could be to bump the version (say, the patchlevel part) after tagging the release?)
• The learn-ocaml/learn-ocaml-client API didn't changed from 0.12
• but the salient change is that learn-ocaml-client 0.13 will support both learn-ocaml 0.12 and 0.13
• and this PR adds the necessary infrastucture so that upcoming changes in the Learnocaml_api could specify supported-versions constraints, in a backward-compatible way.

[erikmd]

Note: a simple test with 0.12 could be added to actually check the cross-version compatibility.

But I guess this can be done in an upcoming GHA-dedicated PR, that would derive from what we implemented with @LouisAyroles in the learn-ocaml.el CI.