Fixes #406

Fixes #1029

While overall parameterless constructors in structs are valid from IL perspective, without a convenient way to declare them they were virtually nonexistent. As we performed more and more testing, we kept discovering cases where parameterless struct constructors caused inconsistent behavior in libraries or even in some versions of CLR.

After reconsidering the potential issues arising from breaking long standing assumptions, we decided it was best for our users to restore the requirement on struct constructors to always have formal parameters.

This reverts commit b37052d0.

Use empty array for unspecified public key instead of default(ImmutableArray<byte>) to avoid issues with JSON serialization

Enable hosts to compile strong-named assemblies on all platforms by supplying public key via compilation options and also enable OSS signing with such key

Been almost a month since the code formatter was run so this change was
a bit larger than would be expected for a normal (weekly) update.  Diffs
mostly around:

- Whitespace changes
- Missing copyright headers
- Missing visibility modifiers

These files are a hold over from when Roslyn was in TFS.  They aren't
needed anymore now that we are in git.

closes #858

Fix #409:
Add explicit StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase where it was intended,
or replace single-char string literals with chars literals.
Also, provide InvariantCulture in TryParse where it was intended.

Fixes #345 and #511

This change reduces the VM used and memory allocated in the emit
tests by moving the WinRT tests to their own DLL and removing
the extra mscorlib reference.

The cause of most of the allocations in the Emit unit tests was
serializing the WinRT assemblies across app domains. There were
three reasons the DLLs needed to be serialized:

1) PeVerify currently requires a separate app domain to be used if
   any of the references of the assembly to be verified have already
   been loaded into the current app domain and have a different MVID.

2) The WinRT tests all use a separate version of mscorlib, so they
   will all reference an assembly with a different MVID than the one
   loaded.

3) Most of the WinRT tests were accidentally pulling two references
   to mscorlib, also always leading to a conflict.

All of these issues should be resolved. The CSharp.Emit unit tests
now allocated 400 MB less and have > 100 MB smaller peak VM.

Fixes #386.

but continue to report the diagnostic if "strict" mode is requested.
Fixes #324

Makes it easier to use the property and fixes a couple of bugs, where the code didn't check for either IsDefault or IsEmpty. Now all use-sites just need to check for IsEmpty.

Fixes 1119812. (changeset 1410494)

     Background:

     As discussed in the dev team all hands all code under the GitHub dotnet foundation is using a single process for contribution, API review, infrastructure and coding style. The idea is to present a unified view to our customer and give them a single story for contributing to any project under the dotnet foundation.

     https://github.com/dotnet/corefx/wiki/Contributing#c-coding-style

     The coding style transition is automated using a Roslyn based rewrite tool:

     https://github.com/dotnet/codeformatter

     This will be applied in stages across our developer tree. Right now the focus is on the Open directory as this is what is being presented on github. Code owners will be contacted before the transition happens.

     Note: this is a soft style requirement. There are no build errors that come from this change.
 (changeset 1408227)

Bug-1116460 : Renaming the scripting assemblies and namespaces. Making corresponding changes in InstallDogfood and RoslynBuildAndTtest to account for new names (changeset 1408119)

Between all of our different processes, xUnit, Jenkins, Test.exe, etc ... our unit tests run on a variety of xUnit runners.  A number of them are unable to handle the following pattern:

     [Fact]
     void M() { ... }
     void M(string arg) { ... }

     Essentially a test method which has an overload in the same type.  This is clearly a bug in xUnit and one that is fixed in more recent versions of 2.0.  We are in the process of updating to that version but it will take a bit more time to do so.  In the mean time I wrote a program to find instances of this pattern and changed the code to work around this temporary issue.   (changeset 1400484)

  <Reference Include="xunit">
    <HintPath>..\..\..\packages\xunit.1.9.2\lib\net20\xunit.dll</HintPath>
  </Reference>

rather than the recently introduced:

  <Reference Include="..\..\..\packages\xunit.1.9.2\lib\net20\xunit.dll" /> (changeset 1397721)

This moves our settings / targets files into the Open directory.  These files are a referenced by virtually all of the projects in the Open directory and are a necessary part of the build process.  Making this change is a necessary step in removing the project scrubber.  (changeset 1396832)

This changes our projects to consume xUnit through NuGet instead of our checked in binaries in Closed\Tools\xUnit.  This is another step in removing project scrubber.  (changeset 1396548)