Drop legacy-mode ruleset conflict detection

Description

The feature to detect when the user has manually configured their local rulesets to weaken the ruleset generated from the Quality Profile should be dropped.

The reasons for dropping the feature are that 1) it's at odds with the "developer-centric" approach of other flavours of SonarLint 2) it's low value, involves a lot of code, and is difficult to maintain

BLOCKED by #1381 - we'd like some additional telemetry to help decide how and when to deprecate/drop this feature.

Background

Currently SLVS adds a ruleset to each MSBuild project during the binding process. This ruleset is empty; it just points to the solution-level generated ruleset.

These project-level rulesets were to support the following feature: 1) Users should be able to customise the rules that are executed per-MSBuild project. 2) However, users should not be able to weaken the set of rules that is run i.e. they should only be able to add more rules or increase the severity of existing rules. The feature is implemented by a "conflicts manager" that compares the "effective" local ruleset against the generated ruleset, looking for differences.

That feature comes from the "central command and control" philosophy that guided the original development of SLVS. It is at odds with the "individual developer choice" philosophy embodied in the other SonarLint flavours.

Notes

This is a legacy-mode-only feature. Other legacy-mode features will not be affected by it's removal. We should decide when/how to remove this feature e.g. deprecate first, or just drop it outright?

Implementation

The ruleset conflict manager (all of the code in SonarLint.VisualStudio.Integration.ProfileConflicts) would be removed, along with the corresponding tests. Product code - 850 lines (6% of the total code base) Test code - 2306 lines (7% of the total test code base)

SonarSource / sonarlint-visualstudio