First pass at `InputManifest`

[alilleybrinker]

This commit is a first-pass implementation of InputManifests, without any logic for actually constructing them. My intent is that they'll be made by a builder type, and be immutable once constructed. To that end, all fields are private and gettable only by accessors (which should generally be inlined to callers to avoid a perf hit).

This commit also implements Display to get the OmniBOR-spec-compliant printed version of a manifest. This included some light Clippy-wrangling to ensure we only do \n newlines.

The next step will probably be to implement the builders.

Signed-off-by: Andrew Lilley Brinker alilleybrinker@gmail.com

[alilleybrinker]

Further thinking: the individual rows shouldn’t expose a Display impl, because it’s only useful in the context of a manifest.

[alilleybrinker]

I’m thinking builders should basically have an ambient storage they’re backed by, pluggably persisted in the file system or a database. When constructing a manifest for a new artifact, it can check the storage for any manifests for referred artifacts, adding in that manifest’s ID if found.

The simplest form of building would basically be to take already-constructed ID’s, rather than things that can be ID’ed. Probably start there and then add the ability for the builder to handle ID’ing things itself.

Probably want that storage API contract expressed as a trait, implemented by some common (and feature-controlled) options. Unlike other traits in this crate and in the GitOID crate, this one won’t be sealed.

We could even go the way of providing storage impls in separate crates to make them more clearly opt-in and avoid “first-class” vs. “second-class” options, though that raises questions around FFI usage from other languages.

[alilleybrinker]

Added initial parsing for manifests on disk. Note that this still preserves the idea that manifests are immutable once loaded in memory.

Still a draft, the new parser code isn't great and also needs to be tested. It's a very rough first pass so I could think through what's needed for parsing.

EDIT: Also, I did a rebase and force push to fix a prior commit not being signed off.

[alilleybrinker]

This PR is ready for final review! It features:

• InputManifest struct
• InputManifestBuilder struct
• Storage trait
  • InMemoryStorage struct
  • FileSystemStorage struct

It can handle construction and querying of manifest data for non-embedding mode, but doesn't implementing embedding mode yet.