Add additional batch endpoints to `LargeSmtForest`

[iamrecursion]

What should be done?

While we currently have the ability to update the forest in an atomic batch (update_forest), we do not have the ability to either add lineages or perform openings or gets in a batch. add_lineages would add multiple lineages in a single atomic batch, while open_many and get_many would simply allow for more performant queries when lots of openings or gets need to be performed at once.

How should it be done?

Implement the following endpoints:

• add_lineages(&mut self, version: VersionId, lineages: SmtForestUpdateBatch) -> Result<Vec<(LineageId, TreeWithRoot)>>: Adds multiple lineages to the forest atomically.
• open_many(&mut self, version: VersionId, targets: Vec<LineageId, Key>) -> Result<Vec<(LineageId, SmtProof)>>: Performs openings for all of the provided targets in parallel.
• get_many(&mut self, version: VersionId, targets: Vec<LineageId, Key>) -> Result<Vec<(LineageId, Option<Word>)>>: Performs gets for all of the provided targets in parallel.

When is this task done?

When the above endpoints have been implemented, tested for correctness using hand-written and property-based tests in both backends, as well as hand-written and property tests. They should also be benchmarked so we have a baseline against regressions.

Additional context

May want to be done after #879 for simplicity's sake.

[AlexWaker]

I have spent some time looking at this one and I think the main work here is not just adding three new APIs, but making sure their semantics fit the existing LargeSmtForest versioning/history model and backend abstraction cleanly.

My current understanding is:

• add_lineages is likely the trickiest part because of the atomicity requirement;
• open_many / get_many look more straightforward functionally, but still need to be designed with the current query/history behavior in mind;
• the test surface will be fairly important here, especially now that forest-level property coverage is improving.

I’d be happy to take this on if no one else is already working on it. I think my property-test expansion in #886 according to #879 should also make this easier to implement and validate, especially for checking batch semantics against the existing single-item APIs.

[iamrecursion]

Thanks so much for your interest! I would rather handle this one myself, as the exact design needs to be informed by library users, particularly miden-node.