Improved Security levels usage

[pinkforest]

Current non-exclusive feature approach has several problems

• One transient dependency can break the build
• Multi-tier dependency trees lose / don't relay feature information - reality in Rust ecosystem
• A single crate using default features will break the build over security level setting

curve25519-dalek used to use features for backend selection pre-4.0.0 and there transient dependencies were setting features they did not offer downstream meaning transient dependency ended up dictating what backend was chosen - if lucky.

• Simplifying backend selection dalek-cryptography/curve25519-dalek#414

Often non-default backends were not be able to used all together due to transient dependency not relaying the desired backend in any single level of whole dependency-chain.

**Improvement Options

Option	Security Level Decider	Multiple Security Levels via crate
cfg[(kyber_security_level)]	Top level binary only	No - top level bin chooses one
crate::1024::x	Immediate dependant	Yes

1/ Use cfg[(kyber_security_level)] = LEVEL predicate

Pro is it leaves the choice of security level to the top level binary.

2/ re-export security levels via public API

e.g. crate::1024::x

Pro about having explicit "intent clear" API for different security levels which may be easier to read, test and audit

x/ pre-RFC

Also there is a pre-RFC about mutually explicit global features but can't be used today.

This can be adopted later if it ever lands given it's not at RFC level yet and RFCs typically have years long leadtime.