If there's multiple cursor positions in the test, each is used for
a find references operation and the output of each result must match
the marked spans. This is useful for linked file scenarios where the
results should be same no matter which linked document it comes from.

Right now you can specify linked files by assembly name, but that's not
helpful if you want to test with two projects with the same assembly
name in the first place.

…y name

The default case for projects not specifying a name is still to use
the assembly name, so this doesn't break existing tests.

This doesn't change the behavior of any tests, but it does make it
easier to understand what is going on when a test with linked files
fails.

Before this change, if you had two projects that had the same assembly
name, you might get weird results from find references. Internally it
used assembly name as a cache key for dependent projects, and so as long
as the two projects with same assembly name had different dependent
projects, we might not actually search all the projects we need to in
your solution.

Further, if you had the same linked file in both of these projects,
we wouldn't search all projects that had it linked. This was because
the LinkedFileReferenceFinder would correcty find all the symbols in
linked projects, but the engine would then dedup the list calling those
equal because once again the assembly names were equal. We make a
decision here that when searching for symbols, symbols from source
should never be deduplicated across projects that define them, but
we will still merge metadata symbols as a single referenced symbol.
There is an argument that we should also split up metadata symbols as
well, but many consumers might find it very surprising that suddenly
they get N referenced symbols in the result if there are N projects
in the solution. For now, we'll maintain the result there.

Fixes issue dotnet#3351.

FindSourceDefinitionAsync, when presented with a source symbol, would
immediately return that symbol. If the source symbol is a retargeted
source symbol, we were still returning that symbol instead of returning
the "original" definition in the other source assembly. This changes the
behavior to now return the original source assembly, a behavior which
seems more consistent and allows FindSourceDefinitionAsync to be used
in scenarios where we care about IAssemblySymbol identity.