[Policy, no patch] Decide if and how security issues should block features in minor releases

This is a follow-up from #2139769: [Policy, no patch] Block 8.0.0 and possibly minor versions on critical security issues., worth reading the discussion there first.

Before we put out 8.1.0, we need to decide how to minimize the security burden of having potentially multiple supported 8.x branches with the same security issue needing to be fixed in each.

A few options were proposed:

1. Block minor releases on critical/highly critical core security issues.

Pros: each minor release would have a 'blank slate' of security issues.

Cons: could indefinitely delay minor releases, which are supposed to be on a 6 month schedule

2. Block minor releases on critical/highly critical security issues older than x months with maintainer discretion

Pros: each minor release would have a 'blank slate' of security issues, apart from ones that were very recently reported, or which for some reason a core maintainer has decided should be deferred until the next release - so hopefully a small backlog.

Cons: could still hold up minor releases indefinitely, issues that are exempted from a minor release add to the backlog for the next one.

3. Block new features (and possibly major refactoring) on outstanding security issues

Pros: ties security issues to the amount of change happening in core - which is often what introduces security issues in the first place

Cons: as with thresholds, can be hard to enforce consistently, and people working on features/refactoring aren't necessarily able to help get the security backlog down.

4. Don't block any minor release on security issues.

Pros: we'd still block 9.0.0 on those issues so the backlog would eventually get back to 0 again - no rollover across major releases

Cons: could still end up with a long backlog.

We don't need to finalize anything prior to 8.0.0, but as soon as that's out, we should bump this to critical for 8.1.x