Consider prioritising crate search directories

[brson]

The way crates are resolved now is by searching all known library paths for libraries with matching metadata. If there is exactly one match then it is used. If there are multiple matches then it's an error. This creates occasional situations where there are (for good reason) multiple crates in different directories with the exact same name, causing compilation to fail.

The most obvious example is when somebody installs the same crate to ./.cargo and to ~/.cargo, making it unusable. One possible scheme is to break the paths up into 'priority groups' and if there are multiple matches with the exact same metadata then the higher priority one wins. If there are muliple matches with different metadata then, even if they are different priorities, it's still an error.

Priority groups from lowest to highest:

• sysroot target libs - where core/std, rustc, etc live
• sysroot cargo libs - if such a thing exists
• user cargo libs - in ~/.cargo
• local cargo libs - in ./.cargo
• all user provided search paths

Most of these groups consist of a single path, except for 'all user provided search paths', i.e. the -L flag. If a user explicitly says where to look for crates then there really shouldn't be dupes.

[catamorphism]

I think #5682 supersedes this.