Default apphost should take platformtarget of app into account

With x64 SDK on PATH:

1. mkdir apphost
2. cd apphost
3. dotnet new console
4. Edit apphost.csproj, set PlatformTarget to x86
5. dotnet run (or execute bin\Debug\netcoreapp3.0\apphost.exe directly)

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'D:\Temp\apphost\bin\Debug\netcoreapp3.0\apphost.dll'. An attempt was made to load a program with an incorrect format

[peterhuene]

I think that RuntimeIdentifier is the “knob” for .NET Core. The problem here is that we have an implicit “runtime identifier” just for the apphost which only occurs when RuntimeIdentifier is not specified. The use of PlatformTarget would only help hint at the desired default architecture for the apphost in this case.

Ideally, this is going to be a temporary measure for 3.0 anyway. I don’t like having to restore for an additional runtime for “runtime agnostic” builds just to get the platform-specific apphost. This will be how it works for the first preview of 3.0, but I’m hoping to replace this before 3.0 releases with a better mechanism that doesn’t pollute your assets graph just to enable this.

[nguerrera]

It occurs to me that fixing this will address a long-standing issue where F5 would use dotnet on path instead of dotnet with matching bitness. The default apphost can save us here. 😁