Split `OmniBor` type into `OmniBor` and `OmniBorBuilder`.

[alilleybrinker]

Ideally, the OmniBor type would be for an immutable record, perhaps deserialized from a source or ready to be serialized to a sink, and mutation / construction of an OmniBor would be through a builder. The API here can pretty closely match the one we have for the GitOid/GitOidBuilder types in the gitoid crate.

[alilleybrinker]

With the renaming in the spec, this should become the ArtifactInputManifest and ArtifactInputManifestBuilder, I suppose. Long names, feels Java-like (not in a good way), but it would exactly match the spec, so I am inclined to go this way.

[alilleybrinker]

More concretely, this relates to the question of how AIMs will be built. Some thoughts:

• Reading a plaintext AIM.
• Reading AIM out of the appropriate section of an ELF binary.
• Constructing an AIM from a set of already-generated GitOIDs.
• Constructing an AIM from a list of files (which we'll need to generate GitOID for).

On the writing side, we'd have:

• Writing a plaintext AIM.
• Writing a binary AIM for embedding in an ELF file.

This also implicates the question of respecting the OMNIBOR_DIR setting. In the current spec, this can be set by environment variable or by CLI flag, with precedence rules defined by the spec. However, the omnibor crate is a library, so we likely want flexibility here. We want to both support handling the environment variable correctly, while also allowing users to ignore it if they have reason to do their own thing.

[alilleybrinker]

Closing this, given the rewriting of the crate.