Minor refactoring of the Library struct

[bobbinth]

Current Library struct looks like so:

pub struct Library {
    digest: RpoDigest,
    exports: BTreeMap<QualifiedProcedureName, Export>,
    mast_forest: MastForest,
}

enum Export {
    Local(MastNodeId),
    External(RpoDigest),
}

There are a couple of things we may want to change here:

1. We are missing some metadata from library definition. One example of this is version but there are also other potential things we may want to track about procedures and the library itself. Regarding version, we should decide if we actually need it, and if not, remove the Version struct from the codebase.
2. We can also consider removing Export enum because information about whether a given procedure is local or re-exported can be inferred from the underlying mast_forest.

[bitwalker]

IMO version belongs to a hypothetical Package struct, the "version" of a Library as I see it, is the content hash returned by Library::digest.

I see Library as basically a thin wrapper around the raw MastForest, providing the core information needed to understand its contents. All the higher-level user-facing metadata should belong to Package, which would be named, have a semantic version, and contain optional metadata like debugging metadata, WIT definitions (or whatever we end up with there), and other elements that aren't really needed once the underlying Library is loaded into the Host.

So, externally, most users are working with Package; while internally in miden-processor and miden-core, we're mostly concerned with Library or MastForest. To the extent that Package is present at all, it might be in the miden-processor, so that Host can be "package-aware".

As for removing Export, I think it's worth checking that we can rely on looking at the underlying MastForest, however IIRC, part of the problem is that when two exports refer to the same MAST node, we're only taking the non-External node, which means when you go to look up the MAST node, for all intents and purposes it will look like that node is a definition and not a re-export. We do this because we can't store multiple nodes under the same digest in the forest. I haven't looked into this in detail though, to see if we can address this differently. Export was essentially the method I landed on to ensure that we didn't accidentally replace "real" definitions with an External node that would then never be resolvable (since node corresponding to the actual procedure definition was replaced).

[bobbinth]

Closed by #1465 (the second point was addressed there and we decided to have metadata at the package level).