[AES-GCM] Cleanup to prepare crate for release

[wysiwys]

Rebased onto main from aes-gcm:

---

[AES-GCM] Cleanup to prepare the new libcrux-aesgcm crate for release

• Addresses the points in [AES-GCM] Cleanup to prepare crate for release #1166
• Reorganize module structure, so that the exported Key, Nonce, Tag type aliases can be found in a module that corresponds to each implementation
• Rename crate libcrux_aesgcm -> libcrux-aesgcm (for consistency with other crates in this repository)
• Apply clippy lints
• Update tests, benchmarks and examples to use libcrux_traits-based public APIs (the ones defined in typed_owned and typed_refs)
• Move libcrux_traits API implementation into separate module
  • E.g. libcrux_aesgcm::aes_gcm_128::neon::{Key, Nonce, Tag}

One other point that was part of release prep/cleanup for this crate:

• Deciding which API will be the main public API for this crate
• Currently, this crate exposes the strongly-typed, key-centric APIs defined in libcrux_traits::aead as the main public APIs. Usage examples for these APIs are provided in the crate documentation and in the examples/ directory.

Closes #1166

[franziskuskiefer]

Looks like there's an AesGcm128 (and 256) in the top level as well as in the aes_gcm_128 module. That's a little odd? Looks like we have multiple APIs exposed here for the same thing.

[jschneider-bensch]

I think this looks pretty good!
Just one check should be added from the initial discussion.

Review re-requested

[franziskuskiefer]

There's lots of code duplication here. That's not great. We should move all checks into the common functions instead.
These implementations shouldn't do much more than passing things along to the actual functions, picking the right one, and converting arguments where necessary.

[franziskuskiefer]

Do we really need all these types? The types aren't different for different platforms.