Fix lock up that occurs when WinForms is executed on the pipeline thread

[rjmholt]

Fixes PowerShell/vscode-powershell#2352.

Dequeuing work to execute on the pipeline thread used to be async/await without using ConfigureAwait(false). This meant that introducing a thread synchronisation context (like WinForms does) could break our thread architecture.

Particularly in the WinForms case, the work dequeuing delegate would be marshalled back to the pipeline thread, which was blocked by the stopped debugger, so unable to execute.

Now we use ConfigureAwait(false) so that the lock delegate's execution is not influenced by the synchronisation context.

[rjmholt]

Cosmetic change to fix misleading indentation

[TylerLeonhardt]

LGTM

[SeeminglyScience]

LGTM!

There's going to be a lot of this littered throughout the code base. We used to have a custom sync context that required us to be more selective about how we configured awaits. Now that we don't have that, we might want to:

1. Set up the analyzer that warns when ConfigureAwait(false) isn't present
2. Configure every single await 🙂. It won't look great, but it'll save us a few out of no where deadlocks

[TylerLeonhardt]

Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 3
- Added 1
           

See the complete overview on Codacy

[TylerLeonhardt]

Issue found: Remove this initialization to 's_hasRunPsrlStaticCtor', the compiler will do that for you.

[andyleejordan]

LGTM!

There's going to be a lot of this littered throughout the code base. We used to have a custom sync context that required us to be more selective about how we configured awaits. Now that we don't have that, we might want to:

1. Set up the analyzer that warns when ConfigureAwait(false) isn't present
2. Configure every single await 🙂. It won't look great, but it'll save us a few out of no where deadlocks

LMAO we finally got around to this, and I did for the OmniSharp library too.