Tidy up wizard code to be able to remove more StyleCop supression entries

[mrlacey]

The GlobalSupressions.cs file (in SolutionFiles folder and used by multiple projects) includes a large number of supressions that were only added to get the checks to pass. The intention was always that these would eventually be tied up. Now is the time to do that tidying.

Anything with the following justification should be removed and violations fixed or given a proper justification if we genuinely need the suppression.

"Initially suppressing everything before evaluating what we want and what's appropriate."

[crutkas]

see issue #867, analyzer isn't in every project. Is that going to affect anything you have? I'll go through and start adjusting.

[crutkas]

Once #867 inside #872 and #869 gets merged, we can roll onto this.

[mrlacey]

All blocking issues (linked above) have been addressed.

[crutkas]

woot!

[crutkas]

is this realistic for 1.3? I would say lets focus on stability at this point.

[mrlacey]

low priority, I vote to punt. This also potentially touches a lot of the wizard code (depending on how much gets addressed) and we should be heading more towards stabilization

[sibille]

Moving to 1.5, we removed a lot of supressions, but left some due to high impact

[ralarcon]

@mrlacey @crutkas Which is left mainly is the code order (private vars, public props, methods...) and I think this is not too much worthy compared to the complexity / amount of work needed. Can we close this issue?

[mrlacey]

I've added a PR which addresses a few more issues.
One of which was a one line change but was suppressed with the justification that it would have a "high impact"

I don't think "We follow the C# Core Coding Style and not require this rule." is a sufficient reason not to address SA1516 (separating elements with spaces)
It will be a big change but will improve readability and consistency to the code. Both these things improve maintainability of code and so save time in the long run. I'll happily make this change but wanted to call out this justification.
No, this isn't explicitly called out in the coding guidelines but that doesn't mean we shouldn't do it. This is also a really weak argument as some of the things I've fixed in the PR are explicitly required by the guidelines. If going to make justifications based on explicitly following the letter of the guidelines this needs to be done consistently to aid credibility and expectations.

I'd also like to address SA1401 (Fields must be private.)
Again this will be a big change but I'll happily do it--if noone else will. My concern with not doing this is that by allowing direct access to private variables we risk breaking encapsulation and that makes code less predictable and harder to understand. The complexity of the code is already high and we should do things to improve this and aid future support and enhancements.

[ralarcon]

SA1516 We addressd others and probably copy an pasted the justification.
SA1401 I don't think there should be too much entries of this.

Agree to adress both

[sibille]

Verified in dev