Add support for specifying the sub-directory of a git repository for forc dependencies

[mitchmindtree]

Implementing #952 should get us support for dependencies in git repository sub-directories.

However as mentioned in that issue, the approach of walking the entire repo may take a long time for large mono-repo projects or cause issues if there is more than one project with the same name for whatever reason.

We should optionally allow the user to specify a particular sub-directory to avoid performing the search if they wish.

E.g. if we have a repository at github.com/owner/repo that has 2 sway libraries in it called foo and bar under respective directories, we should allow for specifying them like so:

foo = { git = "https://github.com/owner/repo", branch = "main", path = "foo" }
std = { git = "https://github.com/owner/repo", branch = "main", path = "bar" }

We might want to bikeshed over what field to use to declare this subpath, as using path might be a little contentious seeing as the same field is already used to describe local dependencies.

Further, in cargo, specifying both path and git for a dependency used to have a different meaning, where path would be relative to the manifest and would override git. I believe this was originally supported in order to allow for a very basic approach of "patching" a top-level dependency for testing. Since then, [replace] was introduced as the proper approach to patching, then it was replaced by [patch], and then finally specifying both path and git simultaneously was deprecated in 2018.

My proposal is to update the meaning of the path field to the following with some clear documentation while we still have a fresh slate:

• In the case that a git repository is specified, path is relative to the root of the repository.
• When no git repository is specified, path is relative to the project's manifest.

[mitchmindtree]

Should note that specifying paths in serializable structs is a speedy way to break portability - we should remember to use some cross-platform serialization approach for Forc.lock.

[adlerjohn]

Seems reasonable!