feat(`foundry-lock`): expose lockfile structure/parsing in public crate

### Component

Forge

### Describe the feature you would like

In [Soldeer](https://github.com/mario-eth/soldeer), we would like to be able to parse `foundry.lock` files so that we can recursively install subdependencies of packages even if they use git submodules themselves.

To do this efficiently, it would be of great help if we could parse the `foundry.lock` file to know which commit to checkout for git submodules, even in the absence of a `.git` folder (which is usually omitted from packaged dependencies).

I started to look into vendoring the [lockfile module](https://github.com/foundry-rs/foundry/blob/2b85d1fbd3647865efdae4c0e17b994638ff722c/crates/forge/src/lockfile.rs) into Soldeer, but it would be a lot of work and I'd have to keep it in sync with any changes upstream, which is bad.

Is there a chance that foundry could extract the logic related to parsing the lockfile into a separate crate which gets published on crates.io? This is because we publish `soldeer` on there and we can't use git dependencies. I'd love to be able to re-use the logic used internally by forge.

Ideally, the crate would pull in minimal dependencies to avoid bloating soldeer.

### Additional context

https://github.com/mario-eth/soldeer/issues/346

Start by reading crates/forge/src/lockfile.rs, the existing lockfile module referenced in the issue, and review the linked Soldeer context. Done means the lockfile parsing logic is exposed through a separate crates.io-publishable crate with minimal dependencies so Soldeer can parse foundry.lock files and obtain git submodule commits without a .git directory.

Written by the indexing model from the issue text.