crypto: split out implementations

[kaspar030]

This is the branch where I'm splitting edhoc-crypto (crypto/) into a dispatch crate and implementation crates, as we briefly discussed.

The main idea is to not have all dependencies of all implementations inside one crate, but seperate them out.

The old crate edhoc-crypto gets a feature for every crypto implementation (hacspec, cc2538). Each implementation sits in their own crate, edhoc-crypto-hacspec and edhoc-crypto-cc2538. edhoc-crypto gets optional dependencies for those crates selected by the features.

~~This already seems fine, the only issue I have is that now when doing a workspace level cargo build, edhoc-crypto-cc2538 fails because it cannot be built for amd64 (cortex-m crate fails building). This seems to be a limitation of Cargo 1. I'll try to think of a solution. In the meantime, I PR this as draft so we can discuss it.~~ Found a solution: populate Cargo.toml [workspace.default-members] without the no_std crates.

edhoc-crypto itself doesn't do anything itself but exporting subcrate modules. maybe we can even just drop it and move the logic into edhoc-rs directly, should we go forward with this split.

[kaspar030]

@malishav I solved the cargo build issue!

Host-architecture cargo build and cargo test still work. So should cargo build --target="thumbv7m-none-eabi" --features="hacspec-cc2538" --no-default-features --package edhoc-rs.

[malishav]

Could you add a simple build test to github actions testing the build with the command above? Other than that, I think this is ready to fly.

[kaspar030]

Could you add a simple build test to github actions testing the build with the command above? Other than that, I think this is ready to fly.

I anticipated that question and admit I was too lazy to teach the workflow how to build for ARM :) doing that now, let me squash before merging once CI passed

[kaspar030]

workflow is updated & fixup commits are squashed!

(I promise, the next build variant I add to the workflow, I'll set up a build matrix)