log when VS has hit low memory barrier

The SourceTextStream type was operating under the assumption that
Encoder.Convert was a non-throwing method so long as it was passed a
destination buffer with at least one byte available for writing.  The
actual contract for Convert is it will not throw so long as it is able
to write the result of converting at least one character to the
destination buffer (or there is nothing to convert).  In that case it
will throw an ArgumentException indicating it attempting to do work but
was unable to do so.

The SourceTextStream type processes the characters in chunks according
to the count passed into Read.  This caused a bug when a character which
was represented with more than one byte value was at the end of a
logical chunk of text.  The Converter would convert all the chars except
the last one.  But SourceTextStream continued processing because there
was at least one byte left in the destination buffer and hence an
exception was thrown.

The fix is to not check for count > 0 when processing but instead count
>= the maximum number of bytes the encoding could produce for a single
character.

Note: I did consider calling GetByteCount here instead but decided
against it.  It essentially forces the encoder to do the work of
decoding the lead byte twice on every iteration of the loop. Seemed
better to keep the simple worst case check here.

closes #1197
closes #1221

These DLLs are of the Implementation variety and should not be
referenced.  The good news is we weren't using them anyways.

This extracts the CoreCompile target from the Microsoft.CSharp.CurrentVersion
and Microsoft.VisualBasic.CurrentVersion targets files and creates two new
targets files, Microsoft.CSharp.Core and Microsoft.VisualBasic.Core, to contain
it.

This is necessary because the CoreCompile target contains the actual invocation
of the Csc/Vbc tasks, which the MSBuildTask assembly contains. Any changes in
the public surface area of the tasks need to be reflected in the targets. These
targets should eventually be inserted into the MSBuild install with the task as
the compiler public entry point.

EE: Non-printable characters should not be escaped when using 'nq' format specifier

Incorporated more feedback from PR#1206.

Small optimization for ModuleMetadata matching...

Don't consider AssemblyFiles that don't contain metadata (resources, etc).

Close #399. Ignore bit flag AssemblyFlags.PublicKey for assembly definitions.

Support VSHPROPID_ActiveIntellisenseProjectContext

Rename nameof attribute

ASP.NET 5 supports switching between target platforms in the IDE via a new hierarchy property, "VSHPROPID_ActiveIntellisenseProjectContext". We now consider this property when determining or setting the active document context and also listen to its hierarchy event.

Fixes #164

EE: Non-printable characters should not be escaped when using 'nq' format specifier

Update test baselines to reflect that the conflict resolution span for
an attribute is now the entire span of the attribute.

Implements SyntaxUtilities.IsClosureScope for VB

Conflicts:
	src/Compilers/VisualBasic/Portable/SymbolDisplay/ObjectDisplay.vb

Ensure Razor lines are editable when debugging an MVC5 project

Handle not-yet-loaded projects in GetENCBuildState

Apply Spacing rules around methodcall inside Attributes

VsENCRebuildableProjectImpl.GetNECBuildState was not accounting for the
possibility that there might not (yet) be a roslyn project for a given VS
project.  If we ever encounter this, we should just report that the
project is unchanged.

We have a number of dumps for this issue, but no concrete repro steps.

Move AllowsReadOnly to VsReadOnlyDocumentTracker from VsENCRebuildableProjectImpl, so we can avoid pass a delegate.

The expander can operate on a specific set of known nodes, so when
rename finds a conflict in a particular node, it uses the span of a
parent that the expander knows how to handle. For normal
ArgumentSyntaxes, this is covered by being within a StatementSyntax.
However, nameof within an attribute constructor isn't in a statement, so
rename needs to expand to the span of the attribute.

Ensure AnalyzerDriver completes during Compilation

Added suppression attribute for FxCop CA2001:AvoidCallingProblematicMethods

Fixes #1196
Closes #1200

Fix #776 : Apply spacing rules around method call inside attributes as
well

Removed the use of System.Runtime.InteropServices.DangerousGetHandle together with FxCop suppression for it.

Rename methods referenced in nameof expressions

Minor refactorings: