Add code fix provider for VSTHRD109

[AArnott]

This required some of the same code fixer functionality already found in the VSTHRD010 code fixer, so a few chunks of code got moved from that fixer into the Utils class.

There are several tested scenarios, but the crux of the fix is that it changes this:

    async Task FooAsync(CancellationToken ct) {
        ThreadHelper.ThrowIfNotOnUIThread(); // VSTHRD109 diagnostic here
        await Task.Yield();
    }

to this:

    async Task FooAsync(CancellationToken ct) {
        await ThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync(ct);
        await Task.Yield();
    }

Note that the code fix automatically finds JTF instance(s) to use (the user picks the one from the fix list), and automatically finds any local CancellationToken to propagate into the switch method call.

Closes #316

[sharwell]

💡 This may work in newer versions of Roslyn with later language versions (bestest betterness). If the underlying issue is the inability to distinguish between Task.Run(Func<Task>) and Task.Run<TResult>(Func<Task<TResult>>), you can force a disambiguation in the test by calling Task.Run<int> instead of just Task.Run.

[AArnott]

Yes, using Task.Run<int> does resolve the issue (see the test directly above this one, on which I applied that workaround).

Interestingly though, although this compiles:

Task<int> t = Task.Run(() => Task.FromResult(1));

Even in that case, which compiles, Roslyn still claims that the delegate returns Task. Yet if it really did, the result couldn't be assigned to Task<int> as I did. So what's up with that? Would 'bestest betterness' actually solve this?

[sharwell]

Even in that case, which compiles,

Are you compiling with the same version of Roslyn as you are using to run the tests?

[AArnott]

No. I compile the analyzers against Roslyn 1.2, and the tests run with 2.3. Evidently the dependency on the new Roslyn test framework bumped up the version of Roslyn I'm testing with.
How does that affect this investigation?

[sharwell]

Evidently the dependency on the new Roslyn test framework bumped up the version of Roslyn I'm testing with.

This shouldn't be the case. The test framework is compiled against Roslyn 1.0.1. The version of Roslyn used for testing is controlled by the following line:

https://github.com/Microsoft/vs-threading/blob/9df4cbf729555494c4a3b2ef9902fbb7dfa81100/src/Microsoft.VisualStudio.Threading.Analyzers.Tests/Microsoft.VisualStudio.Threading.Analyzers.Tests.csproj#L23

Git blame indicates this was updated to Roslyn 2.3.2 in #190.

[AArnott]

I see. I can certainly try to match the versions up (presumably by rolling back the version in the tests). What do you predict will happen? Will it resolve the issue? If so, why?