Haxe Language Support

[piboistudios]

This PR seeks to add full Haxe language support.

It also adds support for custom CheckerTypes collections (so as to allow importing types from other sources than Haxe RTTI XML API; e.g. from a .NET class library)

To-Do:

• Parsing
  • [X] Enums
  • [X] Abstracts
  • [X] Interfaces
  • [X] Enum Abstracts
  • [ ] Multiple var declarations
  • [X] Generic module decls
• Type-Checking
  • [X] Interfaces
  • [X] Enums (?)
  • [ ] Abstracts
  • [ ] Macro
• Interpreting (macro)
  • [ ] Enums
  • [ ] Pattern-matching
    • [ ] Structure-matching
    • [ ] Array matching
    • [ ] Enum Matching
    • [ ] Guards
    • [ ] Or patterns
    • [ ] Variable Capture
    • [ ] Extractors
  • [ ] Abstracts
  • [ ] Macros

[Simn]

I don't really want to stop you, but please note that I don't know if we actually want to extend hscript like this...

[piboistudios]

I don't really want to stop you, but please note that I don't know if we actually want to extend hscript like this...

This is really more an effort at making hscript a viable Haxe-in-Haxe parser/type-checker (and interpreter/eval runtime), as I am using hscript for hxgenPE (and believe me, there were many other considerations... hscript is definitely the closest to a full Haxe-in-Haxe solution here, mainly because it has the workings of an interpreter and type checker for a complete Haxe subset; I could have used hxparse and check style, but how then would I implement macros? Writing yet another eval platform, basically, is the answer to that question).

Also, I like the prospect of using hscript as a unified runtime codegen solution (much like Reflection.Emit/LINQ, but better because working with those is ugly, and not Haxe) that could be used for all new haxe-in-haxe platforms, assuming they use the same approach as hxgenPE.

I think, even if this draft is never merged, it will be referenced elsewhere at some point in the future (e.g. some new Haxe-in-Haxe compiler repo..)