Based on the conclusion in discussion #3248, this PR fix "OEM" and "Default" encoding in powershell.
1. OEM -- We need an internal fix because .Net Core has no "OEM" encoding.
The fix gives the following PowerShell Core behavior on "OEM" encoding:
- on Windows - as Windows PowerShell based on GetOEMCP() and legacy encodings (System.Text.Encoding.CodePages)
- on Unix - the same as default encoding in PowerShell Core
2. Default -- We need internal fix because CoreFX `Encoding.default` for all platforms is UTF8.
Until we complete the `Encoding RFC` we should restore behavior as in Windows PowerShell.
The fix gives the following PowerShell Core behavior on "Default" encoding:
- on Windows - as Windows PowerShell based on GetACP() and legacy encodings (System.Text.Encoding.CodePages)
- on Unix - UTF-8 without BOM (We are expecting that the same will be [in CoreFX](https://github.com/dotnet/coreclr/issues/10643))
- FullCLR build is disabled in this change.
- FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts.
- `dnxcore50` and `portable-net5+win8` target framework monikers are removed.
- Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time.
- I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400
The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information.
Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
Ilya