Add custom verifiers to the test project

[sharwell]

Add verifier implementations, which are used to customize test framework behavior in the context of a specific analyzer project.

[sharwell]

Rebased to no longer depend on #544

[jmarolf]

Why have these as source code in the templates instead of adding them the the library itself?

[sharwell]

The ones in the library cannot be edited as part of the project.

[jmarolf]

I do not understand why these need to be added to the templates

[sharwell]

@jmarolf Creating these helpers is the first step toward using the test library.

https://github.com/dotnet/roslyn-analyzers/blob/master/src/Test.Utilities/CSharpCodeFixVerifier%602.cs
https://github.com/SergeyTeplyakov/ErrorProne.NET/blob/master/src/RoslynNunitTestRunner/CSharpCodeFixVerifier%602.cs
https://github.com/microsoft/VSSDK-Analyzers/blob/master/src/Microsoft.VisualStudio.SDK.Analyzers.Tests/Helpers/CSharpCodeFixVerifier%602.cs
https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/StyleCop.Analyzers/StyleCop.Analyzers.Test/Verifiers/StyleCopCodeFixVerifier%602.cs
https://github.com/microsoft/vs-threading/blob/master/src/Microsoft.VisualStudio.Threading.Analyzers.Tests/Helpers/CSharpCodeFixVerifier%602.cs

[jmarolf]

My question still stands: why not just have these types exist in the library itself instead of the templates?

[jmarolf]

[sharwell]

My question still stands: why not just have these types exist in the library itself instead of the templates?

I answered this in a nested conversation above: #545 (comment)

Having these files as an intermediate layer between the analyzer tests and the SDK means users can customize default behavior if the standard defaults don't make sense for the project. Over time, we'll likely move some of the properties people add to this layer back into the library itself, but it's good to have a central point that can be tweaked/modified.