MSRV policy going forward

[MabezDev]

With #2615 we ourselves in a situation where we have to bump the MSRV even though we're not using any new compiler features on the RISCV side. This is likely to happen again in the future.

The simplest proposal is to maintain two MSRVs, essentially a "arch-specific" MSRV. This will allow us to keep the RISCV one lower, and allow us to bump the Xtensa MSRV when we run into compiler issues.

[bugadani]

We can also specify "latest stable" globally and accept that while a patch release may keep API compatibility, an update may break a build that uses an older compiler. It's semver-compatible, though maybe not the most polite way to approach the issue.

[jessebraham]

The simplest proposal is to maintain two MSRVs, essentially a "arch-specific" MSRV. This will allow us to keep the RISCV one lower, and allow us to bump the Xtensa MSRV when we run into compiler issues.

Not sure I agree with this, this will complicate our MSRV checks in CI and we will not be able to specify rust-version in the Cargo manifest anymore (which maybe is not the end of the world, but does provide a nicer experience when using unsupported toolchains IMO). I also think this will lead to confusion for users.

[jessebraham]

We can also specify "latest stable" globally and accept that while a patch release may keep API compatibility, an update may break a build that uses an older compiler. It's semver-compatible, though maybe not the most polite way to approach the issue.

This is probably a reasonable approach, but will have to think about it.

[bjoernQ]

One advantage of bumping both MSRVs this time would be that we get core::error::Error - implementing it on our error types would be a good thing

Other than that, it's probably not a problem to have "arch specific" MSRVs in general

[jessebraham]

I'm sort of leaning towards stable or stable - 1 at this point, just to make things a bit easier on ourselves with regards to potential future compiler issues. We can always extend the MSRV in the future, and I don't think this is an unreasonable limitation. There is of course always the caveat that things may work with older compiler versions, we will just choose not to officially support them. Curious to hear what others think about this, though.

[MabezDev]

Let's go with STABLE as our MSRV policy. Now that cargo is MSRV aware, this becomes a much more reasonable policy because it avoids random breakage, and clearly tells the user that they need to update their compiler to enjoy the new release.

To complete this work we should:

• Update the various READMEs on this policy
• (Optional) Add a checklist the PR template that checks if the MSRV has been bumped, in which case the README should be updated