* added Microsoft.VisualStudio.IntegrationTest.Setup.vsix to signing

* removed duplicated entry.

* now test setup vsix is part of signtooldata.json no need to have special case for it.

also made exception to have better message

Merging on behalf of @alrz. Thanks!

There were two separate bugs here:
    1) Fixing up the MVID of the binary was being done *after* signing,
    when it should be done before.

    2) System.Reflection.Metadata has a bug where calculating the
    checksum occurs before signing, when it should happen after.

Both of these isues have been fixed and the helper utility that checks
to see whether a binary was signed has been changed to verify that the
signature and checksums of the binaries are valid, not just that the
signed bit is set on the assembly.

Fixes #23521

Merge dev15.6-preview2 to master

Merge remote-tracking branch 'dotnet/dev15.6-preview2' into merges/dev15.6-preview2-to-master-20180104-080013

Removing the rename command target from Roslyn as it will be part of core editor platform

Merge dev15.5.x to dev15.6-preview2

LOC CHECKIN | dotnet/roslyn-master | 20180103

Merge dev15.5.x into master

Correct date stamping logic for the new year

Ideally, we'd apply a version number to our binaries like 20180102
for the 2nd of January, 2018, but the Windows PE file format restricts
each number to a 16-bit unsigned integer. This means even trimming
to 80102 still isn't enough. The solution is to continue to decrement
that 'year' digit, and each time we do so add another 12 to the month.
This buys more time until we can rebaseline where we start.

Add MEF metadata to IDeferredQuickInfoContentToFrameworkElementConverter

Merge dev15.6-preview2 to master

LOC CHECKIN | dotnet/roslyn – master | 20171222

When I added this interface, I had the implementations expose their
applicable type not by metadata, but by simply calling a method on
the instance. This is problematic if the implementation is in a
different assembly as we'll load it too early. This is causing F#
to load when they shouldn't.

This is intended as a temporary shim that fixes the perf load for
the F# case (the only current exporter of these outside the Roslyn
repo itself) without forcing an interface change. This will get deleted
soon enough once we migrate to newer Quick Info APIs.

This change removes the following APIs:
- TypeSymbol.BaseType
- TypeSymbol.Interfaces
- TypeSymbol.AllInterfaces
- NamedTypeSymbol.TypeArguments
- TypeParameterSymbol.ConstraintTypes

These APIs simply delegate the work to APIs with "NoUseSiteDiagnostics" suffix and are not supposed to be used inside compilers. They were left in the code-base because they used to be part of the public surface and the names were nicer, but they are no longer part of the public surface.

* Suggest stackalloc keyword in Span legal places

* Address PR Comments

* More PR Feedback

* Clean up

Remove the TestUtilities Desktop / CoreClr projects

The conditional build of net45 was added when we didn't support any
desktop targetframeworks on Linux. Now that it's supported we should be
building all flavors of the utilities there.

* Pass in optional arguments by ref

* IOperation tree tests

* PR Comments

Fix the blob publishing

The dotnet CLI has been seeing a hang from VBCSCompiler in their build
on non-Windows platforms. The cause is this:

    1. dotnet build starts a child process to do `dotnet pack` and
    redirects its output to a buffer.
    2. `dotnet pack` starts a child process to do `compile`.
    3. `compile` starts vbcscompiler because one is not already running.
    4. VBCSCompiler inherits the output handles from (1).
    5. VBCSCompiler process finishes and processes (1) and (2) exit.
    6. The parent `dotnet build` process  is waiting for (2) to exit,
    which it has, but also to see EOF on its output stream. Because that
    stream has been captured and held open by VBCSCompiler, the EOF
    never comes.
    7. `dotnet build` hangs.

This change fixes the problem by creating new streams for input and
output for the compiler server process. This isn't quite what we do on
Windows -- on Windows we create invalid handles for the input and output
-- but it's as close as we can get using the portable APIs in
System.Diagnostics.Process.

Fixes #23734