Ensure that core and core-test-framework crates support no_std

[jjkurczak]

Issue Link

resolves #134

Summary

Updates core and core-test-framework crates to build with no_std, and configures workspace and other packages to support no_std

Description

What did you do?

This PR incrementally enables no_std support for bouncycastle-core and bouncycastle-core-test-framework. The most consequential changes are:

1. Adding a new alloc feature to a number of crates in the dependency graph of bouncycastle-core in tests mode (hkdf, hmac, rng, sha2)
2. Adding #![cfg_attr(not(feature = "alloc"), no_std)] to crypto/core/src/lib.rs to force no_std when alloc is not enabled for bouncycastle-core
3. Updating crypto/core/src/traits.rs to feature-gate any std/alloc dependent functions in the core bc-rust traits
4. Adding feature gates to various impls that depend on traits.rs in the crate dependency graph
5. Adding _array() functions in traits.rs for convenient alternatives to _out() functions when in no_std mode
6. Updating bouncycastle-core-test-framework to feature-gate test types that are not applicable for no_std (feature-gated trait functions)

Why did you choose this approach?

What alternatives did you consider?

1. I had initially attempted to create a large PR that would cover a few crates at once, but this was too large and accruing merge conflicts
2. I've chosen to create even smaller, incremental PRs that enable no_std (and no alloc) one or two crates at a time to keep reviews manageable, because the scope of the changes to manage no_std is quite large when alloc is also disallowed
3. Although we also intend to support a no_std WITH alloc mode, I think it makes more sense to fully remove std and alloc first since this has bigger implications for the architecture, and add alloc back in later as a smaller step
4. A number of tests are feature-gated in core-test-framework because they are only testing trait functions available in std. Many of these tests do not have duplicates for no_std equivalent behaviours, and these have been noted with // todo: may require no_std equivalent in the code. I believe it will be more efficient to manage adding back parallel tests in their own PR because it will take me some effort to understand and replicate
   all of them correctly.
5. All tests-only code (i.e., integration tests in tests/, bouncycastle-core-test-framework) is not required to support no_std. This would be a lot of trouble to manage, and there is no need to run the tests themselves in no_std environments.

Did you add or update any tests to account for these changes?

No tests added - many tests feature-gated for no_std builds, see reasoning above.

Is there anything else the reviewer should keep in mind?

1. For the moment, only core and core-test-framework can build, test, or benchmark individually with --no-default-features. Building with --no-default-features, or otherwise disabling alloc, for any package other than sha2 or sha3 (including when building --workspace), is currently an unsupported configuration.
2. No changes have been made to github actions to validate --no-default-features builds - it seems like this should be managed once the entire workspace of packages is capable of being validated for --no-default-features? Is it worth spending the effort to mess around with the github actions for each sub-issue, so each set of packages is validated as they begin to support no_std, and then refactor for the entire workspace functioning at the end?
3. bouncycastle-core-test-framework does NOT enforce no_std in its crate, even without the "alloc" feature, because it will only run for tests/dev-builds

Scope and Risk

Which packages are impacted?

• This change impacts core, core-test-framework, hkdf, hmac, rng, sha2.
• Nearly all changes relate to disabling code when the alloc feature is not enabled, so default builds using alloc should ideally see no change.

What runtime behaviors could be impacted?

It's unlikely that any changes in this PR will impact runtime behaviours - I would expect to see breaks at compile time rather than at runtime.

How likely is it that there could be unexpected regressions?

What could go wrong in the worst-possible scenario?

There are two major areas of risk I've identified:

1. There are widespread changes to workspace and package .toml files to create the alloc feature in many packages, and to ensure that dependencies only inherit alloc when needed. There could be unexpected dependency breakages when bulding packages if the dependencies have been misconfigured.

Validation

1. build, test, bench workspace should continue to function as expected (bench manually)
2. build, test, bench individual packages should continue to work as expected (build, test, bench manually)
3. build, test, bench core and core-test-framework packages individually with --no-default-features flag should work, with reduced test coverage (test manually)

AI Usage Statement

Did you use AI in creating this pull request:

• No
• Yes, indirectly - no submitted code was generated by AI (e.g., answering questions, performing a review, suggestions, etc.)
• Yes, trivial code changes were generated by AI (e.g., autocompletion of a single line, reformatting, or spell-checking)
• Yes, non-trivial code changes were generated by AI

If submitted code changes were generated by AI, fill in the following declaration:
Assisted-by: ClaudeCode:Sonnet5