Update CMakeLists cmake_minimum_required to suppress warning

[keithw]

cmake 3.31.6 prints a warning when configuring projects that specify a minimum version of < 3.10. This updates the version range to suppress the warning:

CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.10 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

[keithw]

@BurningEnlightenment Gentle ping on this. I'm hoping to switch wasm2c over from using SHA-256 (via OpenSSL, and a lot of users are having trouble with that dependency) to BLAKE3 by importing this repo as a submodule, and it would be nice to land on a commit that doesn't raise a build-time warning. So getting this in would be much appreciated.

[BurningEnlightenment]

@keithw sorry to string you along, I'm on vacation till Monday. I know these version ranges are en vogue, but I'm a bit uncomfortable with them, because it requires you to test with every CMake version which introduces new policies 😕

Therefore I wanted to survey the Linux distros to determine whether we can safely raise the minimum required version.

[keithw]

Gentle ping on this. We're definitely not wedded to this particular approach -- any way of getting rid of this build-time warning would be great.

[BurningEnlightenment]

I chose CMake 3.18 as the upper version bound for policies as the vast majority of users
should be using newer CMake versions--CMake 3.18 is shipped in the
current LTS version of Debian (11). Furthermore it precludes some of the
more significant policy changes introduced with CMake 3.19, i.e. we
should get away with not testing the build with every CMake version.

In the future I'll aim to keep the lower bound aligned with the oldest supported RHEL and the upper bound tied to the oldest supported Debian LTS version. Updating the upper bound should always entail careful review of the affected policy switches.

@oconnor663 looks like the rust CI jobs fail due to the deprecation of GenericArray (I've already rebased on master). Since this is totally unrelated, I plan to merge this tomorrow regardless of the rust CI status.

[oconnor663]

Yes known problem upstream: RustCrypto/traits#2036. I see that CMake tests are green, so I'm going to merge. Thank you both!