After a hash mismatch error, emit file-system paths of crates involved.

Fix #13266.

There is a little bit of acrobatics in the definition of `crate_paths`
to avoid calling `clone()` on the dylib/rlib unless we actually are
going to need them.

The other oddity is that I have replaced the `root_ident: Option<&str>`
parameter with a `root: &Option<CratePaths>`, which may surprise one
who was expecting to see something like: `root: Option<&CratePaths>`.
I went with the approach here because I could not come up with code for
the alternative that was acceptable to the borrow checker.
Added session.fileline_note() method and support infrastucture for it.

Add way to print notes with just file:linenum prefix (preserving
integration with source lookup for e.g. vi and emacs) but don't repeat
the other span info.
Accumulate list of paths for crate hash mismatch.

(i.e. semi-generalized version of prior errorinfo gathering.)

Also revised presentation to put each path on its own line, prefixed
by file:linenum information.
Rough regression test for #13266.

All it checks, unfortunately, is that you actually printed at least
two lines for crateA paths and at least one line for crateB paths.
But that's enough to capture the spirit of the bug, I think.  I did
not bother trying to verify that the paths themselves reflected where
the crates end up.
auto merge of #13284 : pnkfelix/rust/more-fs-info-on-crate-mismatch, r=alexcrichton

Fix #13266.

There is a little bit of acrobatics in the definition of `crate_paths`
to avoid calling `clone()` on the dylib/rlib unless we actually are
going to need them.

The other oddity is that I have replaced the `root_ident: Option<&str>`
parameter with a `root: &Option<CratePaths>`, which may surprise one
who was expecting to see something like: `root: Option<&CratePaths>`.
I went with the approach here because I could not come up with code for
the alternative that was acceptable to the borrow checker.