Use QCheck.Print combinators in Util.Pp printers for consistency

[jmid]

In #565 I discovered that STM argument and result printers differed causing a negative nan to display as nan as an argument to Set, yet it would print as -nan in the result, sending me on a goose chase. #562 was another example of outputs differing slightly.

Following the principle of least surprise, this PR switches all Util.Pp printers for base types to use the QCheck.Print combinators. I believe this further makes sense, since our opam packages are named with a qcheck prefix.

I don't claim that, e.g., the QCheck.Print.float printer is perfect as witnessed by the expect test output updates (e.g., infinity is valid copy-pasteble OCaml, whereas inf is not) but I would rather have to only improve such a combinator in a single, central location.

[jmid]

Ah dang, a negative nan is just printed as nan on macOS, MinGW, and MSVC it seeems, but as -nan on Linux, Cygwin, musl, ... 🤷

ddcebf1 removes the negative nan expect test case (temporarily) in order to move forward with the PR.

[jmid]

I don't claim that, e.g., the QCheck.Print.float printer is perfect as witnessed by the expect test output updates (e.g., infinity is valid copy-pasteble OCaml, whereas inf is not) but I would rather have to only improve such a combinator in a single, central location.

I've opened an upstream issue on QCheck here: c-cube/qcheck#353

[jmid]

CI summary for ddcebf1: All 50 workflows passed

[jmid]

CI summary for merge to main:

• Cygwin 5.4 timed out in Lin Bytes test with Thread Deadlock in Lin Bytes test with Thread on Cygwin #526

Out of 51 workflows 1 workflow failed with (what appears to be) a genuine issue