This reverts commit e16d38bc.

Improve handling of My.InternalXmlHelper

NavigateTo shouldn't consider generated files.

Do not run through following phases in Rewriter.LowerBodyOrInitializer once errors are encountered.

Import parameter's default constant value from metadata even if parameter is not optional.

Make MetadataReference.CreateFromAssembly obsolete

Dont auto-format some keys when smart indent is off

...as in Dev12.

Harden access to MetadataReader

Skip over partial methods with no implementation when emitting extra …

C# EnC: handle addition of indexer

Also add a check that the span returned by
`ISyntaxFactsService.TryGetDeclaredSymbolInfo()` in SyntaxTreeInfo is valid.

Two things were preventing the EE from finding the type, which is needed
for XML literal operations in VB:

1. It is marked internal and the accessibility check happened in
AssemblySymbol, rather than the binder, so it was not hijacked.

2. It is marked with EmbeddedAttribute and is not from the SourceModule of
the compilation (it's from the module of the current frame).

We can resolve both of these problems by doing the lookups as though we
were in the module containing the current frame.  This required two
changes:

1. Remove InternalXmlHelper from WellKnownTypes and give it its own code
path.  Explicitly pass the appropriate module symbol to the new helper.

2. In Binder.CheckViability, look for a containing module before falling
back on the SourceModule of the compilation.

By preserving the accessibility checks during type lookup (but doing them
from the perspective of a different assembly), we retain the compiler's
protection against pulling in a copy from each VB reference (i.e.
ambiguity).

The main caveat is that My.InternalXmlHelper will not be found if it was
not embedded in the module containing the current frame - even if it is
unambiguously available in a referenced assembly.

Breaking change: unlike dev12, roslyn will only find My.InternalXmlHelper
in the source module.

Fixes #964

Fix format rule for dot expression after label

Treat .csx/.vbx as regular source files from command-line compilers;
change *ParseOptions.WithKind(SourceCodeKind) to internal; and
throw NotSupportedException from CSharpParseOptions and VisualBasicParseOptions
constructors if SourceCodeKind is Interactive or Script.

[These changes should apply to the 'stabilization' branch only.]

As a result of the changes, a significant number of unit tests are now skipped.
(Search for SCRIPTING define and #2888 to find the test changes.)

Fixes #2774.

Ensure that calls into EnvDTE.CodeModel work even if the underlying FileCodeModel has not been realized

Handle analyzers which have enabled rules, but no registered actions.

Customer scenario: Analyzer author writes a bolier plate analyzer that defines the rule that it intends to implement in future, but registers no analyzer actions for analysis. Adding such an analyzer to your analyzer assembly brings down the entire analysis, and no analyzers execute during command line build. The issue was reported for StyleCopAnalyzers package which has many such to-be-implemented analyzers.

Fixes #2980

Fix description: Add a null check around the place we compute set of all registered actions for analyzers.

Testing: Added regression tests + existing tests.

Improve debugging experience around exception filters

Customer scenario: Analyzer author writes a bolier plate analyzer that defines the rule that it intends to implement in future, but registers no analyzer actions for analysis. Adding such an analyzer to your analyzer assembly brings down the entire analysis, and no analyzers execute during command line build. The issue was reported for StyleCopAnalyzers package which has many such to-be-implemented analyzers.

Fixes #2980

Fix description: Add a null check around the place we compute set of all registered actions for analyzers.

Testing: Added regression tests + existing tests.

Ensure BoundLValueToRValueWrapper nodes are marked as compiler generated.

Port2966

Fixes #2793.

Correct the copyright header on four files.

Ensure that calls into EnvDTE.CodeModel work even if the underlying FileCodeModel has not been realized

When calling into an EnvDTE.CodeModel API, the caller must pass the file
name of the file to be operated on. For example:

var ns = codeModel.AddNamespace("MyFile.cs", "MyNamespace");

However, the implementation EnvDTE.CodeModel would only ever succeed to
find the FileCodeModel for "MyFile.cs" if had already been created and
cached. If the FileCodeModel wasn't in the cache, the API that was
called would throw.

Ultimately, this comes down to a set of APIs with bad names that don't
reflect that they only return cached values. This change renames those
APIs to give them proper names (e.g. TryGetCachedFileCodeModelInstance)
and adds an API that will retrieve a cached FileCodeModel or create a
new one if needed.

Fix cast simplification to not offer cast removals for following cases:

1. Explicit numeric casts in explicit checked/unchecked context
2. Non-identity pointer-to-pointer conversions.

Fixes #2691

Description: Fix is to bail out early for these cases. As we are now more conservative, we cannot regress in offering any additional incorrect cast removals. #2987 tracks improving on this conservative approach post 1.0 milestone.

Testing Done: Existing cast simplification tests.

Approved by MattGe.

1) Explicit numeric casts in unchecked context
2) Non-identity pointer-to-pointer conversions.

Fixes #2691

Description: Fix is to bail out early for these cases. As we are now more conservative, we cannot regress in offering any additional incorrect cast removals.

Testing Done: Existing cast simplification tests.

Fix NullReferenceException in DependentProjectsFinder when we have an InternalsVisibleTo attribute with a null constructor arg.

Generate relative paths correctly.

**Bug:** Fixes #1579.

**Customer Scenario:**
The customer wishes to use a shared rule set file in their project to control their diagnostics. The .ruleset file is at the root of their solution, so the customer adds it to their project as a linked file. They then set it as the active rule set by right-clicking on the file in Solution Explorer and selecting "Set as Active Rule Set".

The file should become the active rule set for the project, turning various diagnostics on or off or altering their severity. Instead the customer gets an error in the Error List: "The file '..\\..\\..\\Rule.ruleset' cannot be found" and the rule set has no effect.

**Fix:**
When adding `..` to the relative path to backup to higher-level directories, we effectively add each one multiple times. The fix is to stop doing that.

**Testing:**
I manually tested the following variation on the original scenario:

* Rule set file in the same directory as the project file
* Rule set file one level above the project file
* Rule set file two levels above the project file
* Rule set file up two levels and then down in a subdirectory
* Rule set file one level below the project file
* Rule set file two levels below the project file
* Rule set file on a different directory

and verified that in each case the project file ends up with the correct path, and that the rule set takes effect as expected.

I also added unit tests to exercise the affected code.