Add support for native cs type parameter constraints

[kLabz]

Allow one to define native C# constraints from haxe.Constraints.Constructible or cs.Constraints.*. This is useful when using C# APIs using such constraints for inputs; without it we need "ugly" workarounds.

Supported native constraints:

• where T : struct with cs.Constraints.CsStruct
• where T : class with cs.Constraints.CsClass
• where T : unmanaged with cs.Constraints.CsUnmanaged
• where T : new() with haxe.Constraints.Constructible<Void->Void>

For example, this:

import cs.Constraints;

@:nativeGen
class Main<T:CsStruct> {
	public function new() {}
}

Will result in:

public class Main<T> where T : struct {
	public Main() {
	}
}

See Microsoft's documentation on the subject for reference.

[Gama11]

Is this a case where @:coreType would make sense to avoid the abstract needing a (Dynamic) underlying type?

[kLabz]

Could be; although from Dynamic (or something nicer) would still be needed.

[RealyUniqueName]

Add a test, please.

[Gama11]

cs_ver should probably be added to define.ml so it shows up in haxe --help-defines?

[kLabz]

Notes on tests:

• TestCs class may seem redundant but is actually required to make sure the generated where constraints are present in the generated C# code so that we can use C# APIs requiring them.

• Both static functions and classes are tested in Main.hx, again it seems to be redundant but it makes sure native constraints work in both places

• Unsupported combinations as documented on MSDN are tested in incompatible-combinations-fail.hxml. This includes the undocumented incompatibility between class and struct (both have to be the very first constraint).

[kLabz]

Should add

	{
		"name": "CsVer",
		"define": "cs_ver",
		"doc": "The C# version to target",
		"platforms": ["cs"]
	},

in #8195 if this is merged.

Edit: #8195 has been merged, and this PR has been updated.

[kLabz]

@Gama11

Is this a case where @:coreType would make sense to avoid the abstract needing a (Dynamic) underlying type?

Should I do this? I used haxe.Constraints as a model for cs.Constraints, but I can change it (and maybe update haxe.Constraints too?).

[Gama11]

I'm not sure, is there a reason why haxe.Constraints types are defined the way they are @Simn?

[kLabz]

simn
@:coreType typically has a specific native representation which is handled by the target generator

Rudy G
Would you say then that @:coreType would make more sense in cs.Constraints since they generate native c# type parameter constraints?
(and not necessarily in haxe.Constraints)

simn
Yes if these typed are picked up by the generator you can use @:coreType
Abstracts over Dynamic are for when the run-time representation is not specified.

I updated cs.Constraints to use @:coreType (and not haxe.Constraints) and rebased development again, waiting for CI ~