Allow configurable Microsoft.Quantum.Sdk version in language server automatically-generated .csproj

[rmshaffer]

Is your feature request related to a problem? Please describe.
In latest beta builds from master, the language server is creating a temporary project to compile and provide IntelliSense features for .qs files that do not have an associated .csproj file in the folder.

The temporary .csproj file generated contains a reference to the Microsoft.Quantum.Sdk version that matches the version of the currently-installed extension (specifically, the version of the language server that is running). There is no way to customize the version of the Microsoft.Quantum.Sdk reference.

Describe the solution you'd like
For testing purposes it would be useful to have a setting to specify a different Microsoft.Quantum.Sdk version. It would also be nice to log the version of Microsoft.Quantum.Sdk used at the time the .csproj is generated.

Describe alternatives you've considered
No real alternatives here other than manually installing a different version of the extension and/or editing the .csproj manually after it is generated, neither of which are reasonable workarounds.

[AE1020]

Relatedly (?), it could be useful to have a way to be able to point at a directory containing a locally built qsharp-runtime in the process of compilation in general, independent of the SDK. (I'm not familiar enough with the msbuild/nuget ecology to know if there's an easy way to override such resolutions from the outside.)

I was just trying to run a "Hello World" using a locally built compiler. The suggested test in the README.md of printing "Hi from your locally built compiler!" on startup gave me the message. But after that, I received an error regarding SyntaxExtensions coming from qsharp-runtime's CSharpGeneration. This is described in another issue as being due to the runtime being out of sync with the compiler.

It seemed like it would be forward-looking to figure out how to build the current qsharp-runtime and point to a local copy of that. This was difficult (for me). The CSharpGeneration DLL location doesn't seem to have any override in the SDK itself, the way you can specify <QscExe> and <QscBuildConfigExe> (Note: the latter option is not documented in the SDK Readme, is that intentional?)

What happens is that if you have <CSharpGeneration> as true, you get hardcoded versions of dependencies coming from SDK.props, in the case of CSharpGeneration it is:

<PackageReference Condition="$(CSharpGeneration)"
     Include="Microsoft.Quantum.CSharpGeneration" Version="0.15.2101126940" IsImplicitlyDefined="true"
     IsQscReference="true" ExecutionTarget="Any" Priority="-1" PrivateAssets="All" />

This leads to an absolute path in a generated file called build.config...which makes its way to a --load parameter in qsc.rsp. You can manually edit the qsc.rsp file and put a path to your own built copy of Microsoft.Quantum.CSharpGeneration.dll and it works. But the files are regenerated each time you build.

I tried setting <CSharpGeneration> to false, and then manually adding an <AdditionalQscArguments> with a --load of the locally built CSharpGeneration dll. But that dropped a lot of other things out of the --references list that were needed.

In lieu of a better answer, being able to specify <QscBuildConfigExe>, permits one to use a hacked up BuildConfiguration.Generate...which permits being arbitrarily invasive on the config generation process.