//! Components, their associated signatures, and some useful methods.
//!
//! Whereas a [`ComponentBundle`] owns a `Component` and its
//! associated [`Signature`]s, a [`ComponentAmalgamation`] references
//! a `ComponentBundle` and its containing [`Cert`]. This additional
//! context means that a `ComponentAmalgamation` can implement more of
//! OpenPGP's high-level semantics than a `ComponentBundle` can. For
//! instance, most of the information about a primary key, such as its
//! capabilities, is on the primary User ID's binding signature. A
//! `ComponentAmalgamation` can find the certificate's primary User
//! ID; a `ComponentBundle` can't. Similarly, when looking up a
//! subpacket, if it isn't present in the component's binding
//! signature, then an OpenPGP implementation is supposed to consult
//! the certificate's direct key signatures. A
//! `ComponentAmalgamation` has access to this information; a
//! `ComponentBundle` doesn't.
//!
//! Given the limitations of a `ComponentBundle`, it would seem more
//! useful to just change it to include a reference to its containing
//! certificate. That change would make `ComponentAmalgamation`s
//! redundant. Unfortunately, this isn't possible, because it would
//! result in a self-referential data structure, which Rust doesn't
//! allow. To understand how this arises, consider a certificate `C`,
//! which contains a `ComponentBundle` `B`. If `B` contains a
//! reference to `C`, then `C` references itself, because `C` contains
//! `B`!