Add Path Dependencies

[u-train]

Resolve #7 and set up the scaffolding for #6 as well.

The route taken is using project files. To use, simply put in your dependency `"fs+path/to/package". However, they are forbidden if you want to upload your package to a registry.

Issues
I left some issues(?) that should be discussed that might fall out of scope.

• SourcePackageId should be renamed with the word registry instead. For example, perhaps "RegistrySourceId".
• Manifest's registry field should not use a string and should instead use an enumeration similar to SourcePackageId. This applies to the lock file as well.
• Should PackagePaths only take relative paths?
• Shouldn't the resolution saved which registry the package came from?
• How should the lockfile section of the README.md be updated?
• Is the current implementation good?

Changes (I can remember)

• Added PackageLocation, PackageOrigin, and PackagePath.
  • PackageLocation is used in the manifest for where a package is located. This could be in a registry or a path.
  • PackageOrigin is used in Resolution to track where the package is located with more specificity.
  • PackagePath is a path to a package.
• Snapshots have been updated.
• Added new test for installation and upload with regards to package paths.
• Installation will check if the package link is made correctly.
• Upload will forbid any packages with path dependencies.
• Added the lockfile format for paths.
• Added is_suitable_for_registry method for manifest.
• Changed TempProject's leak method to be simpler.
• Resolution now takes a root_dir for package resolution.
• try_to_use argument for resolve now takes a BTreeMap<PackageId, PackageOrigin>
• Lockfile now has a method called get_try_to_use.
• DependencyRequest now takes PackageOrigin.
• ResolvePackageMetadata also now takes PackageOrigin instead of PackageSourceRegistry.
• Installation can now handle PackageOrigins.
• README.md has been changed so that it demonstrates the new feature.