Prepare release

[mbarbin]

Take the opportunity of the next release to revisit a bit some files in the repo. As stated in CHANGES.md:

• Upgrade to ocamlformat.0.26.2.
• Fmt the code
• Add CI badge to README
• Upgrade GitHub workflow actions dependencies (checkout@v4, setup-ocaml@v3)
• Add more validation steps in CI
• Add ocamlformat as dev-setup dependency

[mbarbin]

@rgrinberg I have noticed the CI for the Dune project itself (workflow.yml) has a refined include section where you limit the various combinations of arch, os and ocaml versions. Given the CI failures here, I am inclined to add a similar section for the pp project as well. What do you think?

In particular, macos-latest, 4.08.x is not going to work due to the constraint: available: !(os = "macos" & arch = "arm64").

I wondered how that last couple of PRs in this project succeeded. The logs have expired so I wasn't able to look in details, but this target is green in for example #19. (?)

[rgrinberg]

Yeah, that sounds fine. Dropping 4.08 altogether is also fine.

[mbarbin]

Dropping 4.08 altogether is also fine.

It wasn't exactly straight forward to do, as 4.09 has the same issue, and various other versions have other build failures.

I attempted to identify the exact set of CI combinations that do not fail at the moment. I did not expect to encounter that many failures, I am not sure if something unusual is happening. Aren't we going to encounter the same failures when ocaml-ci is going to run during the PR validation on opam-repository? Shall some additional constraints be added to the pp.opam file?

Beside these side questions, I think this PR is ready for review.

[mbarbin]

@mbarbin assigned @rgrinberg now

I meant to request a review, please disregard.

[rgrinberg]

I personally don't use this workspace file. So feel free to delete it unless you're using it.

[mbarbin]

Ack, I removed it.

[mbarbin]

@rgrinberg I noticed creating 'Merge commit' isn't enabled for this repo. What's your preferred mode of operation between 'Squash and merge' and 'Rebase and merge' in general for this repo? For this PR I lean towards keeping the commit history (I cleaned it up a bit), so planning on merging with a 'Rebase and merge'. I'll try creating smaller PR next so 'Squash and merge' can feel more natural. Sounds OK?

[rgrinberg]

If the commit history is useless (individual commits don't build/work), then I prefer squashing. Otherwise squash & merge is fine. I re-enabled it for this repo.