Add security policy, post-v1.0 MSRV bump policy

[Shnatsel]

Based on the discussion in the relevant Zulip thread: #simd > v1.0.0

[DJMcNab]

One question I do have is what counts as a security backport. E.g. if one of our operations doesn't meet the specified semantics, that can be a security issue in a downstream crate (e.g. one doing cryptographic hashing, say). But then silently updating the implementation to have different semantics is a Hyrum's law nightmare.

I'd be tempted to specify "soundness" as the baseline boundary, and leave everything else unspecified. In a scenario where we do discover a method doesn't work as documented, I'd expect us to probably backport the deprecation and providing a new fixed method, rather than updating semantics. (Although I wonder how that works for core::ops impls!)

Aside from that concern, this looks great. And being overly vague with what counts as a security issue is fine - I don't expect this policy to ever come up in practice.

[Shnatsel]

@LaurenzV I'd like to hear from you as well before we commit to this.