Add an MSRV policy to the README

This is a bit of a tricky topic, as the Rust ecosystem is waiting on
better Cargo support to make usability better, and there is a lot of
differing opinions and theories on how best to handle an MSRV. Not a
lot of concrete data out there. The Rust compiler itself explicitly only
supports the latest stable version, so any MSRV policy is essentially
how long you're willing to wait for dependents of your library to
upgrade.

This can always be changed, but I wanted to have something in place to
make sure that it's covered.

See:
- rust-lang/libs-team#72
- time-rs/time#535

README.md

@@ -1,9 +1,12 @@
-# RustOps Blueprint   [![CI Status]][actions]
+# RustOps Blueprint   [![CI Status]][actions] [[!MSRV]][rust-version]
 
 [CI Status]:
   https://img.shields.io/github/actions/workflow/status/EarthmanMuons/rustops-blueprint/rust.yml?event=merge_group&label=CI&logo=github
 [actions]:
   https://github.com/EarthmanMuons/rustops-blueprint/actions?query=event%3Amerge_group
+[MSRV]: https://img.shields.io/badge/MSRV-1.64-blue
+[rust-version]:
+  https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field
 
 **A GitHub repository template for a polished Rust development experience.**
 
@@ -16,6 +19,15 @@ Generated [Rustdoc][] reference documentation can be found at
 
 [Rustdoc]: https://doc.rust-lang.org/stable/rustdoc/
 
+## Minimum Supported Rust Version (MSRV) Policy
+
+- We follow an "N-2 policy," supporting the curent stable Rust release and the
+  two preceding versions.
+- Our MSRV only advances when we adopt a feature from a newer Rust version. We
+  do not increase the MSRV systematically with each new release of Rust.
+- MSRV increases are considered regular changes, not breaking changes, in terms
+  of Semantic Versioning.
+
 ## License
 
 RustOps Blueprint is distributed under the terms of both the Apache License