Switch to netcoreapp1.0

Instead of using `dotnet publish`, we can use `dotnet build` and the new
`netcoreapp1.0` framework with a new dependency on
`Microsoft.NETCore.App` to generate output that does not include the
runtime, but can be run anywhere (given the installation of the
runtime).

While we cannot yet adopt a dependency on the shared host until .NET
Core RTM, we are forced to switch to this system anyway because the
latest RC3 packages and CLI do not support `netstandardapp1.5`. See
dotnet/cli#2482.

Thus we're in an in-between state where we have to use `netcoreapp1.0`,
but cannot use `"Microsoft.NETCore.App": { "type": "platform" }` to
utilize the shared host, as we need to continue to ship our host.
Without specifying "platform", we retain the status quo with respect to
build steps and outputs.

Additionally, there is no longer a good reason to use the RC3 packages,
and it has been advised we switch to RC2 since the
`Microsoft.NETCore.App` is only available for RC2. We must update
packages because our current version can no longer be debugged.

docs/building/windows-full.md

@@ -51,11 +51,11 @@ module.
 Because the `ConsoleHost` project (*not* the `Host` project) is a
 library and not an application (in the sense that .NET CLI does not
 emit a native executable using .NET Core's `corehost`), it targets the
-framework `netstandard1.5`, *not* `netstandardapp1.5`, and the build
+framework `netstandard1.5`, *not* `netcoreapp1.0`, and the build
 output will *not* have a runtime identifier in the path.
 
 Thus the output location of `powershell.exe` will be
-`./src/Microsoft.PowerShell.ConsoleHost/bin/Debug/netstandardapp1.5/powershell.exe`
+`./src/Microsoft.PowerShell.ConsoleHost/bin/Debug/netcoreapp1.0/powershell.exe`
 
 While building is easy, running FullCLR version is not as simple as
 CoreCLR version.