5.x Release strategy from 4.0.0

[pinkforest]

Proposal

TL;DR Make 5.x a "Performance release" with good defaults whilst merging to-be-tested additions behind features e.g.:

Breaking changes can be gated as optional within 4.x's first before making them defaults at 5.x.

This eases testing in the wild via these "unstable features" and elevates the confidence to adopt as default(s) in 5.x.

1. If it needs a deprecation we could always feature-gate it for 4.x as an optional additive non-breaking feature and then make it default 5.x after battletestign in the wild if so desired - like we're doing for the wasm/armv7 curve25519_dalek_bits case.

I think for 4.0.x also we could have auto-detection for backends as an optional additive non-breaking feature auto and then make it default in 5.x.

e.g. then this would make:

4.0.0 was mostly paying down the maintenance techdebt that is breaking people's builds atm and causing dependnecy duplication leading to long buildtimes 🥳

5.0.0 could be a performance oriented release that contains a lot of well known better defaults for performance.

Also I've proposed some feature flags which we could include this type of work via earlier perhaps:

• Separating backends into their own crates? #287 (If we can get around LTO)
• Implement ABGLSV-Pornin multiplication #323
• Performance features and #[inline] #468

We should probably collect and round-up the various features here and how to incorporate them - I'll make a list here.

[rozbb]

Nice! I like the idea of feature gate -> default pipeline for new functionality. That way we don't have to commit to the API. Some things can probably skip this though, like the ABGLSV-Pornin mult.

Also for deprecation we can just mark things as "will be deprecated in 5.0" and it probably won't count as "breaking"