MSRV policy

[bavshin-f5]

At the moment, we neither set the rust-version in the manifests nor test it in the CI. It would be nice to address both items.
I'm still undecided between 1.82 (17 October 2024) and 1.79 (13 June 2024) and don't see compelling arguments to go below that. I'm sure these will be quite old by the time we consider the project stable.

Non-exhaustive list of benefits we could get from the recent Rust releases (as per https://releases.rs/):

1.83.0 (unreleased)

• const_refs_to_static

1.82.0

• addr_of(_mut)! macros and the newly stabilized &raw (const|mut) are now safe to use with all static items
• Stabilize &raw const and &raw mut operators
• Stabilize nested field access in offset_of!

1.81.0

• error_in_core (could be useful for planned no_std conversion)

1.80.0

• Stabilize LazyCell
• Stabilize lots of NonNull methods

1.79.0

• RHEL 9.5 system toolchain
• Propagate temporary lifetime extension into if and match expressions.
• Stabilize <*const T>::is_aligned and <*mut T>::is_aligned
  (I intend to use these for assertions, even though we assumed that everything coming out of ngx_p(c)alloc is sufficiently aligned. Certain Rust types require 16-byte alignment)
• MSRV-aware cargo add (but not the MSRV-aware resolver)

1.78.0

• MSRV for wasmtime v26

1.77.0

• C-string literals
• cargo:: syntax in the buildscripts

1.76.0

• Stabilized ptr::{from_ref, from_mut}

1.75.0

• Stabilize async fn and return-position impl Trait in traits
• Stabilized mem::zeroed in const contexts
• Stabilized several pointer arithmetic methods

1.71.0

• We currently need this to build

1.63.0

• Debian 12 (stable) system toolchain. Let's not do that.

[bavshin-f5]

1.82 seems too new after all.
1.79 is old enough to be available even in RHEL, so #98 sets the MSRV to 1.79.0 and adds the CI validation.

Leaving the issue open because we want to document some kind of policy, even as arbitrary as "n-2" or "what's available in $distro".