initial support for F#

[brettfo]

tl;dr - Editing/running F# snippets in Try .NET and displaying diagnostics.

Oh boy, is this a giant pile of hacks.

I'm creating this PR so early in the process to get feedback on how to better architect these changes, because right now I'm rather ashamed of what I've done.

List of sins and why I committed them (pun intended):

1. Workspace servers: Rather than try to factor out all the calls to RoslynWorkspaceServer and properly abstract them, I created WorkspaceServerMultiplexer which simply looks for the suffix .fsproj on the workspace type to redirect to FSharpWorkspaceServer; otherwise it defaults to RoslynWorkspaceServer. As I understand it, this will only work for on-disk workspaces which just happen to set their type to the project file path (see item 1 below). I've mostly plumbed through a Language property, and otherwise auto-detected it from the .fsproj suffix for the workspace servers.
2. In an attempt to reuse as much as possible (meaning less plumbing), I hijacked various functions to explicitly look for F#-specific file extensions and then bail in a different direction. See BufferInliningTransformer.cs, FileExtensions.cs, and SourceTextExtensions.cs. A method in BufferInliningTransformer.cs has been made virtual to allow for F#-specific overriding.
3. Markdig doesn't understand code fences of the type fsharp, so to get it to appropriately classify F# blocks as AnnotatedCodeBlocks, I had to lie and say it was C#. The proper fix for this should be adding F# support to Markdig. Turns out it's not Markdig, but this repo; I found and updated the language parsing.
4. F# can't perform compilations and analysis on purely in-memory data structures like Roslyn can, so I introduced RedirectedPackage which creates a directory under %TEMP%, copies everything from the parent Package, and does the text substitution and all work there. (This also explains why I do source path mapping for F# diagnostics in Library.fs.) After compilation the bin/$(Configuration) directory is then copied back to the 'real' location to allow execution. See item 6.A below.

Things that still need to be done:

1. Allow a workspace to properly state it's preferred server: RoslynWorkspaceServer or FSharpWorkspaceServer.
2. Parameterize the hijacked methods and call sites to make the separation cleaner. See item 2 above. Cleaned up as much as possible for this PR. Will be cleaned up even more when enable language as property of workspaces #254 is integrated.
3. Implement completion in FSharpWorkspaceServer.cs (future PR).
4. Implement signature help in FSharpWorkspaceServer.cs (future PR).
5. Add F# tests and fix whatever other tests I most certainly broke.
6. (Long lead) update the F# libraries to allow in-memory compilation and analysis.
   A. In the short term we could likely hijack the call to dotnet build and pass an additional property, /p:OutputPath=path\to\original\project\bin.

Uninteresting note: The C# runner uses #region/#endregion tags to designate which parts of the file to display in the editor. F# doesn't have the concept of regions but other tools cheat and use the specially-formatted comments, //#region and //#endregion, so I also opted for that approach.

[jonsequitur]

"//#region" [](start = 49, length = 11)

Is this ideal? Any suggestions for making it more natural in F#?

[brettfo]

Not really; F# doesn't have the equivalent of #region or any concept of a code block. The closest thing we have is computation expressions, but that would require the writer of the documentation/sample to define a new builder for each span of code. E.g., the backing code could look like this:

type DemoRegionBuilder() =
    member __.Zero() = ()

// ... elsewhere
let demo_region_1 = new DemoRegionBuilder()
let demo_region_2 = new DemoRegionBuilder()
// .. repeat for every equivalent of `#region demo_region_X` that would be found in C#

[<EntryPoint>]
let main(args: string[]) =
    let _ =
        demo_region_1 {
            printfn "hello, world" // this line appears in the web page
        }
    0

With the markdown looking like this:

` ` ` fsharp --project ./MySampleProject.fsproj --source-file ./MySampleFile.fs --region demo_region_1
printfn "hello, world" // this line appears in the web page
` ` `

Adding @KevinRansom to see if he has any additional insight, but I'm still leaning towards specially-formatted comments, because that's essentially what C#/VB #regions are anyways.

[jonsequitur]

"newlineify" 😆

[brettfo]

Slightly shorter than newlineificize.

[jonsequitur]

There's a potential inconsistency here in that I can do this and it will be valid:

```c# --project ./something.fsproj
```

[brettfo]

My plan (hope?) was to merge as-is to feature/fsharp (where this PR is targeted) and then do a merge in from master to get @colombod's changes that add a language parameter to the workspace object and clean up the various hacks I added around detecting the language.