Tuples: adding feature flag

This reverts commit a96d7825.

and for each one, either
1. address the issue, or
2. ensure that there is an issue tracking it

This reverts commit 92ff3f8d.

Adjust style in PatternVariableFinder
Fixes #9530, #9531

This reverts commit b03e8478.

https://github.com/dotnet/roslyn/commit/b03e84783806dc48f240e56188e6473323dc3ba1

The flag name is "IOperation". Register opeartion actions and calling
SemanticModel.GetOperation while the feature is disabled will throw an
InvalidOperationException. Also log a non-fatal-watson when
SemanticModel.GetOperation crashes.

language features (/features=patterns) and more experimental features not
yet fully supported (/features=patternsExperimental).

Fixes #4696.

Fell out of our normal cadence for this during the push for RTM. Now that we
had a bit more breathing room getting us back on track here.

Fixes #2725

Add a new switch '/errorlog:' to VB and C# command line compilers to log all the compiler diagnostics into a log file.
Add command line parsing tests and error log content validation tests.

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.

     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)

 Make tests passing on a non-English OS, even in presence of corresponding localized resources. In the process several product issues were fixed like:
     - Localized exception messages incorporated into diagnostics by command line compiler are not obeying /preferreduilang switch.
     - Some strings are loaded from resources at the time when diagnostic object is created. Resources are loaded earlier than they could be. When error message is requested, it might not be localized in accordance with the requested culture.
     - When target culture is not provided, DiagnosticInfo objects used as arguments within another diagnostic object are formatted using InvariantCulture, whereas all other arguments use current culture (as expected). Portions of the message are localized to different languages. (changeset 1392630)

still outstanding is the target-type conversion to FormattableString and IFormattable. (changeset 1383442)

The principal change here is to remove the language version "experimenal." However, there are a number of places in the code where we either set the language version to experimental or check whether experimental features are enabled. Those are largely vestigal at the moment as we have no experimental features. However as soon as we add experimental features that code will once again be useful. Rather than deleting that code now, I wanted to leave it in and make it easy to find and update as features are added. So I'm adding a stubbed implementation of the API proposed for future use for enabling experimental features.

After Dev14 our plan is to have experimental features enabled one-by-one rather than all under a single umbrella "experimental" flag. Since language features affect the parser, this is part of the parse options. This changeset adds a stubbed version of the proposed APIs:

public class ParseOptions
{
    /// <summary>
    /// Enable some experimental language features for testing.
    /// </summary>
    public ParseOptions WithFeatures(IEnumerable<KeyValuePair<string, string>> features);

    /// <summary>
    /// Returns the experimental features.
    /// </summary>
    public abstract IReadOnlyDictionary<string, string> Features
    {
        get;
    }
} (changeset 1369555)

Making instance field and property initializers in structs an error. Making the instance constructors in structs not experimental. (changeset 1342196)

ReportQueryInferenceFailed – replace hardcoded strings with SyntaxFacts.GetText calls. (changeset 1339108)

There are a number of design and implementation issues with the "Warning as Error" and "Warning treated as error" prefixes shown on C# and VB warnings that have been promoted to errors:

1.) The prefix is redundant. The command line already prefixes the issue with "error" if it is being treated as an error, and so the additional prefix is not needed. For example:

Before:
         error CS0168: Warning as Error: The variable 'x' is declared but never used
After
         error CS0168: The variable 'x' is declared but never used

Inside VS, the Error List icons display the same information.

2.) The prefix redirects the user's focus from the issue itself to the fact that is has been promoted from an warning to an error. It is more noise than help.

3.) The VB implementation is just weird.

C# simply adds the prefix to the message and leaves everything else alone.

VB, however, outputs two errors when treating a warning as an error. One is the original issue with the original error code and message, just as an error. The second is an error with a special "Warning treated as error" error and the prefixed message. However, this extra error is only issued once for a group of issues, even if multiple issues in that group should be promoted to errors.

4.) C# and VB have completely different implementations for the same feature. In VB, the core compiler layer handles adding the prefix and generating the second error. In C#, each compiler host (csc.exe, vbcscompiler.exe, VS, etc.) is responsible for adding the prefix to the message. This makes it difficult for other compiler hosts to report errors the same way csc.exe/vbc.exe do, and difficult to merge errors from multiple sources (such as happens when running a build from within VS).

After some discussion, it was decided that the low (or non-existent) value provided by this "feature" did not warrant the implementation complexity, and it should be removed. (changeset 1337219)

That is - regardless of the presence of parameterized or primary constructors.

In this implementation if a struct without a primary constructor has initializers and parameterless constructor is not present, we synthesize one to ensure that "new S1()" runs initializers.

***NO_CI***
 (changeset 1332600)

Porting the "Dictionary initializer" from an old feature branch related to the now cut ".$" operator.

===
Introducing Dictionary initializers

The syntax is like this:

        var l = new Cls1()
        {
            ["aaa"] =
            {
                ["x"] = 1,
                ["y"] = 2
            },
            ["bbb"] =
            {
                ["z"] = 42
            }
        };

===
Also fixes #13
***NO_CI***
 (changeset 1312685)