Fix issue10550 Desktop FSI accessing System.Configuration

[KevinRansom]

Fixes#10550 : Error accessing System.Configuration.ConfigurationManager in F# Script and F# Interactive on Visual Studio 16.8.0

On the desktop FSI did not pre-load : System.Configuration which meant that when using types from that assembly they couldn't be found. On the coreclr build of fsi, all framework assemblies are pre-loaded, which allowed it to work.

This PR adds System.Configuration to the list of identified framework assemblies for pre-load and to identify core framework types.

And it adds a regression test.

[cartermp]

Hmmm. It's not referenced by default in a desktop C# console app. Are there additional .dlls we pull in for desktop FSI by default that aren't the default in a console+desktop setup?

[KevinRansom]

@cartermp yes ... tons.

 yield "mscorlib"
yield "System"
yield "System.Xml"
yield "System.Runtime.Remoting"
yield "System.Runtime.Serialization.Formatters.Soap"
yield "System.Data"
yield "System.Drawing"
yield "System.Core"
yield "System.Configuration"
yield getFSharpCoreLibraryName
if useFsiAuxLib then yield getFsiLibraryName
// always include a default reference to System.ValueTuple.dll in scripts and out-of-project sources match getDefaultSystemValueTupleReference () with
| None -> ()
| Some v -> yield v
// These are the Portable-profile and .NET Standard 1.6 dependencies of FSharp.Core.dll. These are needed
// when an F# script references an F# profile 7, 78, 259 or .NET Standard 1.6 component which in turn refers // to FSharp.Core for profile 7, 78, 259 or .NET Standard.
yield "netstandard"
yield "System.Runtime" // lots of types
yield "System.Linq" // System.Linq.Expressions.Expression<T> yield "System.Reflection" // System.Reflection.ParameterInfo
yield "System.Linq.Expressions" // System.Linq.IQueryable<T>
yield "System.Threading.Tasks" // valuetype [System.Threading.Tasks]System.Threading.CancellationToken
yield "System.IO" // System.IO.TextWriter
yield "System.Net.Requests" // System.Net.WebResponse etc.
yield "System.Collections" // System.Collections.Generic.List<T>
yield "System.Runtime.Numerics" // BigInteger
yield "System.Threading" // OperationCanceledException
yield "System.Web"
yield "System.Web.Services"
yield "System.Windows.Forms"
yield "System.Numerics"

[KevinRansom]

@cartermp I guess it was a scripting usability thing. To avoid developers having to write:
#r @"C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Numerics.dll"
in order to use bigint etc ...

[cartermp]

Looks good!