Adding dotnet core support to hxcs

[hxgrounds]

Hello, guys.

I have been working for a while to implement support for dotnet core into the hxcs compiler. So, i have made this pull request to know if you want to integrate the changes into the project.

The contributions can be divided into 2 main parts:

1. A refactoring of the CSharpCompiler, breaking its internal implementation into multiple classes, in order to make modifications and testing easier. [commits from 6b42916ccb8ea3e1d3a627560e586bba3b3f40f7 to 936e1a981e563a1d6f8e2a3dbb0e2f10ca761405]
   • As part of this change (and to ensure nothing breaks the compiler), i have added some unit and system tests to the compiler.
2. The implementation of the compilation process using dotnet core cli, based on the new implemented architecture. [commits from a4220c2dab7a68936e94116bd6331262df715275 to 5858fb93c8cd0e6574fb0c111b33602a74d43d20]
   • To ensure compatibility is maintained, i have keeped this new toolchain as opt-in, enabled using a flag '-D dotnet_core'.
   • I have also added another flag '-D outputExtension=newExt', which allows to change the extension of the generated output. This was made to keep compatibility with some tools. Since hxcs has always generated executables with 'exe' extension (and libraries with '.dll'), while dotnet core may use other extensions according to the operating system.

A few warnings:

1. The tests needs some dependencies to work: munit, hamcrest and proxsys.
   • Disclaimer: i am the author of proxsys. I have created it to work as an abstraction of some haxe sys and file functions, to enable testing the interaction with these parts.
2. Personally, i have used lix dependency manager to keep the dependencies. But i have not committed the related files, since i don't know which are the preferences of the project on this topic.

I have documented the main points on the README. So i hope it will not be difficult to anyone install dependencies and understand the proposed architecture.

---

I am sorry to have made all these changed without consulting before, but i hope these contributions will be useful for the community.

If any changes are needed, please tell me, and will add it here.

Thanks.

[mesheets]

I am hoping this overall pull request able to receive some attention.

In the interim, a comment I would have regarding this pull request is in build-tool/csproj-template.mtt, and specifically around line 17:

<TargetFramework>net::targetFramework::</TargetFramework>

I realize this part of the template for an SDK-style project follows the prior pattern of hard coding in a prefix of the <TargetFramework>, but I would prefer that there be no hard coding or assumptions as to what the Target Framework Moniker (TFM) might be. Many do start with "net" as a prefix, but not all. If the TFM provided to Haxe with SDK-style project files is the same as the TFM used by dotnet, then that might also offer a level of consistency. (Even if all the TFMs aren't supported now, it would make it easier to add support in the future.)

Would there be any issues with replacing the line noted above with the following (and updating the documentation accordingly)?

<TargetFramework>::targetFramework::</TargetFramework>

Regardless, though, I again hope this overall pull request is able to receive some attention that will lead to a new version of hxcs being released…. :-)

[mesheets]

Is the added "-D dotnet_core" flag intended to deprecate the "netcore" and "netcore-ver" flags (c.f. Haxe PR 8391)? That PR didn't add support for SDK-style project files, though.