Update sensors to support projects with linked (shared) files

[henryju]

Description

Recent versions of SonarQube allow to have files 'attached' directly to the root project (= the solution). This feature is used by the scanner for MSBuild to support "shared" files. Note that we say "shared" but in fact it can just be a file outside project basedir.

Shared.cs
/projectA
  /-- FileA.cs
/projectB
  /-- FileB.cs

For example projectA can reference Shared.cs (using ../Shared.cs in its .csproj file).

With the current step, the C# Sensor will run on projectA, projectB, and root project.
If some issues are reported by Roslyn on Shared.cs, it will be in the projectA and/or projectB output files (Roslyn json and protobuf files). The problem is that in SonarQube Sensor API, a module can't access files outside current basedir. So nothing will be reported on Shared.cs.

When the Sensor run on the SonarQube root project, it will look for output files like if it was a normal solution's project. But it is not and it lead to such messages:

13:53:17.468 DEBUG: 'shared/Class1.cs' indexed with language 'cs'
13:53:17.468 INFO: 1 file indexed
...
13:53:17.514 WARN: Protobuf file not found: null\output-cs\encoding.pb
13:53:17.514 WARN: Protobuf file not found: null\output-cs\metrics.pb
13:53:17.514 WARN: Protobuf file not found: null\output-cs\issues.pb
13:53:17.514 WARN: Protobuf file not found: null\output-cs\token-type.pb
...
13:53:17.514 WARN: Protobuf file not found: null\output-cs\token-cpd.pb
...
13:53:17.514 INFO: Importing analysis results from C:\Workspace\SONARMSBRU-335\null\output-cs

Expected behavior

The C# Sensor should properly support shared files: importing issues found during analysis of projects using the file, but also highlighting, cpd tokens, ...

The tricky point is that the same file can be referenced in multiple projects. For highlighting & co, this is simple: just take the first results from protobuf files.
For issues, in theory, different issues could be reported depending on how the file is used (is there any X file analysis?). It means some issue deduplication algorithm should be used (like in SonarCFamily).

One technical option would be to make the C# Sensor a global Sensor (ie running only once for the whole analysis).

[henryju]

This is https://jira.sonarsource.com/browse/MMF-825

[Evangelink]

Investigations on this ticket show that this will result in a major change on the SonarC# plugin. IMO this means that there should be a joint sprint with a member of the scanner team to help use refactor the plugin to handle linked files.

We will also have to answer some questions like: if one of path doesn't exist what shall we do (fail, continue)? Can we link a file to multiple SonarQube modules or do we have to link this file to the other module? Will it be possible to report an issue on a file that is totally outside of the project structure?
For example:

/Folder1
  /-- MySolution.sln
  /MySolution
    /-- MySolution.csproj
    /-- MyClass.cs
/Folder2
  /-- SomeFile.cs (this file is referenced by MySolution.csproj)

Finally we should plan some time to make extensive tests to ensure we are covering edge cases and that the old correct behavior is still working properly.

[dbmeneses]

Fixed