Support for 64-bit integers

[mfp]

This PR adds support for 64-bit integer fields and param binding. I was able to test signed integers (full range from -9223372036854775808 to 9223372036854775807), but not unsigned integers yet -- the code is very similar though, making it less of a leap of faith.

Even though they compile, I was not able to use the stress tests: they segfault in the unmodified tree as of 862877a6dd966e61df563205a81e9cd8cf2e296a

Credits

The work on this PR was performed in the context of Ahrefs open-source work day: https://twitter.com/javierwchavarri/status/1466774912148910088

[paurkedal]

I agree this is a good addition (CC @tatchi who mentioned it in #61). I don't have write access to the branch of this PR, so I've pushed my suggestion to [my own 64bit-integers branch](https://github.com/paurkedal/ocaml-mariadb/commits/64bit-integers/]:

• I merged the current master branch (avoiding some conflict resolving of a rebase).
• My third commit allows some extra conversions, which for int may overflow.

The rationale for the possibly overflowing conversion of int is simplicity and backwards compatibility, see also my commit message. We could consider raising an exception in case of overflow.

If you want to add more commits, can you merge in (parts of) my branch first, or rebase in cherry pick?

[paurkedal]

I wanted to do a rebase due to the many changes to the master branch since the PR was opened. If you agree I suggest we merge #66.

This is a backwards incompatible addition, due to extending the public polymorphic variant value and because some results which earlier were coerced into an int now is returned through one of the new cases, so I think we need a new major release. I'm contemplating whether we can do anything to make backwards compatibility less fragile to new additions. (I would have preferred a regular variant, or a fully abstract API, but that will be another breaking change in itself.)