Decide on a policy on how to handle URLs and clashing project names
Currently the way Nimble treats package names and URL's in `requires` list in Nimble files causes issue. 

For example having `packageA` and `github.com/foo/packagea` in the nimble files for two dependencies in a project can potential result in non-deterministic behavior. One case would be to have two separate paths of the same module (`--path:packagea_path` `--path:github_foo_packagea_path`) passed to the compiler. Though I believe the SAT code currently avoids this. Alternatively a package will get chosen based on the insert order of the packages lists as they're generated, which seems to depend partly on the order of iteration of Nimble packages.

One really bad result of this indeterminate order _could_ be a hijack a package name with a hostile package injected via another dependency which adds a trojan URL into it's nimble requirements. For example project `bar` could add `requires "github.com/_bad_hacker/foo"` which has a `foo.nimble`. When Nimble runs `printPkgInfo` on the package cache after an update then Nimble might choose `github.com/_bad_hacker/foo` instead of the official `github.com/cooluser/foo` because say it uses `treeWalk` or similar to parse package info. Note that I _haven't_ tried this, and it's possible the code avoids this issue. It'd also depend on the end-users OS and other details as well.

Personally I think the way Elixir's `mix` package manager handles it is the best, but it requires specifying the package name as well as the URL in it's dependencies format for packages not in the official catalog. In Elixir that's done as a tuple `{:other_package, "~> 2.0", git: "github.com/foo/packagea"}`. Then if as an end-user I want to fork a library and use it I can do `{:other_package, "~> 2.0", git: "github.com/user/packagea_fork", override: true}`. However, Nimble `requires` doesn't support this and packages are already specified purely via URL. 

A benefit about treating the URL or source as extra metadata in `requires` means the name conflict can be raised before running SAT or even cloning a repo/package since the name is already included. The user can then specify what they want to do. If it's a legitimate fork then the user can override the default name.

One solution for example would be to modify `requires` to allow `requires (name: "foo > 0.2", git: "github.com/cooluser/foo", override: true)`. This also avoids the need for Nimble to do network requests to test is a requirement is a git or hg repo, etc.`. Just one thought.

IMHO, the randomness of URL handling is a pretty big issue to have in the 1.0 release. Especially as a fair number of widely used packages in the nimbleverse are reference via URLs.
