Revert "Revert "Revert "Revert "*DON'T MERGE INTO MASTER* Hide IOperation API behind a feature flag""""

This reverts commit d4d502e4.

- Feature flag.
- Syntax model changes.
- Parsing.
- Binding (for explicitly typed variables only).
- Flow analysis.
- SemanticModel – added new API GetDeclaredSymbol(ArgumentSyntax) to return symbol for the declared local.

Basic scenarios work end to end.

Since "original" is by itself contextual on the presence of "replace", only "replace" actually needs to be keyed off a flag.

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)