feat: add compile_error! when no crypto backend is enabled

[DCjanus]

Summary

Restrict the library implementation so that, when no crypto backend feature is chosen, the crate halts immediately at the intended compile_error! instead of compiling the rest of the code.

Details

• Moved the original lib.rs body into src/lib_inner.rs and gated it with #[cfg(any(feature = "ring", feature = "aws-lc-rs"))] include!("lib_inner.rs");.
• Left the existing compile_error! in lib.rs, ensuring it is the only thing compiled when no backend feature is enabled.
• Added a crate-level #![allow(macro_expanded_macro_exports_accessed_by_absolute_paths)] so existing macro usage keeps working under the new layout.

Why

Previously, turning off all crypto features caused a long cascade of “module not found” errors despite the guard. By preventing the remaining modules from compiling without a backend, the build now stops immediately with the clear message.

Reproduction

cargo check --no-default-features

• Before: numerous unrelated compilation errors obscured the real issue.
• After: a single compile_error! reminding users to enable ring or aws-lc-rs.

Compatibility

• No behavior changes for users already enabling aws-lc-rs (default) or ring; normal builds still pass.
• Builds that omit crypto backends now fail immediately with the intended guidance.

[Eugeny]

Is moving the bulk of lib.rs into lib_inner.rs actually required here?

[DCjanus]

Initially, I tried adding a conditional compile_error! directly in lib.rs, but the compiler still proceeded to parse the rest of the modules. This resulted in many “use of undeclared crate or module” errors that obscured the real issue (see this commit).

I then attempted to apply a file-level #![cfg(...)] attribute, but due to the scope of the //! documentation comments, that approach caused new compilation errors.
For this reason, I moved the main implementation into lib_inner.rs and conditionally included it via include! in lib.rs. This ensures that when no crypto backend feature is enabled, only the compile_error! is compiled, and the rest of the code is never parsed.

Another possible approach would be to create a dedicated module that encapsulates all ring and aws-lc-rs usage, so that external code depends only on this module, with feature-based branching handled internally.
However, that change would be larger and might increase the review burden. If you think that structure would be preferable, I can adjust the implementation accordingly and send an updated PR for review.

[EpicEric]

What about removing ring as a feature, and making that crate the default when the aws-lc-rs feature (which would still be a default feature) is disabled? This would ensure that exactly one crypto backend is available no matter the configuration.

[Eugeny]

@EpicEric thank you, however I've ultimately decided to proceed with this PR to avoid having to unconditionally compile ring in every case

Even though features officially must be additive, multiple large crates (e.g. sqlx) simulate mutual exclusivity this way