Create the Packages.props and FixedPackages.props.  These are the files
which will contain our MSBuild mapping from packag name to package
version

The trait NetCore was being unconditionally passed as the trait option to our unit tests.  That mean all tests were being filtered
to those which had the trait NetCore which is a very small number.  Fixiyng it to only be passed when running the net core suites

Break was inserted via bad copy / paste in the following

https://github.com/dotnet/roslyn/commit/970cf1762ed422df17a7a22646be0d178d1c139f

My motivation for doing this is to pick up the new PublicAPI checker
that understands type forwards. In doing so I disabled a bunch of new
warnings that are either broken or not really applicable to Roslyn.
One new warning (don't rethrow exceptions with throw ex;) seemed useful
enough to keep on so I left it on and fixed the one offense in the
codebase.

Based on discussions with SDK team, attempting to switch to using
`$(OutputPath)` for controlling our output directory instead of
`$(OutDir)`.  This is how the SDK recommends teams do it and need
to validate whether this will work for us or not.

This wasn't previously flagged because this only comes into play if there is an error.  As
written the code will display "$echo isn't a variable" instaed of the actual error.

In order to leverage LUT testing we need to have both of the
follownig packages in our build.

- xunit.runner.desktop
- xunit

Both of these include xunit.abstractions.dll in different forms: content
and reference respectively.  This creates a double write violation in our
build.

I've spoken with the xunit team and at this point they believe the
feature is executing as designed.  The content use in xunit.runner.desktop
is meant to support 1.X clients who can't reference the package.

I'm still working with them to find a better way to exclude this but
for now this will remove the race in our build.

Issue #18573 will remain open to track the handling here and find
a better solution.

There is no good method today for executing windows commands with
dynamically built argument lists in Powershell.  This change attempts
to address that by introducing Exec-Command which uses the .NET
Process API directly.  This makes it straight forward to build windows
commands that rely on windows style parsing and output

The clearing of $LastExitCode in our Exec function is masking failures
of windows commands.  Cannot understand why this is the case but easy to
demonstrate in practice.

In cibuild-legacy.ps1 we cannot use Exec-Expression because it's a
bootstrapping problem.  Hence we have to use Invoke-Expression directly.

Even though we invoke a script via Invoke-Expression here we still must
check $LastExitCode.  In the case where the script exits explicitly with
an exit code this doesn't actually cause $? to be $false.  Hence we
still must check both values here.

This change fixes two problems in our powershell scripts

1. Removes all uses of Invoke-Expression.  This commandlet doesn't do error checking on windows
commands and hence can hide failures.  Relpaced with Exec-Expression which properly checks
both the windows command error and the powershell error
1. Reset $LastExitCode inside Exec before executing the script block.  This avoids cases where
previous windows command failures could carry over to a script block that didn't execute any
windows commands.

Powershell guidelines changed appropriately

https://github.com/dotnet/roslyn/blob/master/docs/contributing/Powershell%20Guidelines.md

At this point the Concord project exists just to fix a signing issue in
the Debugger NuGet packages.

This project is causing problems in our port to the new SDK because it's
a Net 45 portable project that is referenced by Net 20 projects.  The
old build silently ignores this incompatibility but the new SDK takes
issue with it, and the method it uses to pass DLLs around.

Taking the simpler approach here of just fixing the signing issues (side
thread going with debugger team) and removing the project.

This was meant to be done as part of my rework of netci.groovy but it looks like I missed
it.

https://github.com/dotnet/roslyn/commit/8a078fac5c497b61f00505d3fe4cf0d92137bef3

Since we will try to repalce the logic with existing rewriter, it makes more sense to
minimize the code change here. Also removed the corresponding tests, will fix and add
them back after the implementation is finalized. As result, the contract for
IHasArgumentsExpression.ArgumentsInEvaluationOrder in C# is broken.

Some NuGet targets also use this property and they expect a trailing
slash to be present

* print submission json file

* call run-ci directly

* use run_perf.ps1 instead

* use correct cibuild parameters

* fix semicolon

* print environment

* add debugging writelns

* fix perf strings

* more debug

* print after parse

* better debug string

* use string concat

* use list for arg building

* underscore submission name

* use branch equals

* fix syntax

* fix console writing of submission json

* change things back

* fix comma

Powershell is used pretty heavily throughout our repo.  This establishes
some guidelines to approach authoring these scripts.

The motivation for this change is to simplify our build and develop
steps.

Previously our compiler builds included files generated into the Obj
folder during previous phases of the build.  This meant that in order to
open Roslyn.sln successfully the code needed to be built first.  Not
ideal.

The generated code involved is rarely changed.  But in order to build
the generators themselves must be built and run as a part of every
build.  This is doable but adds unncessary overhead to development and
complicates our build files a bit.

This approach checks in the generated files which should have the
following benefits:

- Roslyn.sln can be open after a restore
- Build process is simplified and marginally faster for many operations
- Generated code now participates in GitLink