Add repository-level discovery for vendored dependencies

[andrew]

This supports git-pkgs/git-pkgs#317. Project and workspace manifest selection is tracked separately in #55.

git-pkgs needs package-manager-aware discovery of vendored dependencies. The existing Parse(filename, content) API handles one recognized file at a time, while vendoring often depends on configuration, an inventory file, and files elsewhere in the repository.

Examples include:

• A tracked node_modules tree, where each package.json contains the vendored package's own name and version.
• Go's vendor/modules.txt, which lists module paths and versions.
• [tool.vendoring] in pyproject.toml, which points to a destination and requirements file.
• Cargo source replacement configuration, which can point to a custom directory containing crates and .cargo-checksum.json markers.
• Composer's configured vendor-dir and its composer/installed.json inventory.

Add vendor discovery alongside Parse, using the rooted repository reader from #55. The result should include classified vendor roots and vendored package identities with their evidence path.

The first implementation should support tracked node_modules, Go vendor/modules.txt, Python [tool.vendoring], and Cargo directory sources. Composer and other package managers can be added through the same API.

Vendored results need an explicit kind or role so consumers can:

• Treat their exact versions as resolved.
• Avoid parsing dependency declarations under a vendor root as project declarations.
• Preserve the inventory or package metadata path for history and output.

Keep Parse usable as a pure single-file operation. Repository access should remain bounded by the reader supplied by the caller so historical Git trees do not require a temporary checkout.