Only allow Void in return types

[Simn]

I think we generally agree that we want to disallow Void for type parameters, but this by itself would be pointless if we still allowed typedef NotVoid = Void. This PR disallows loading Void for anything that's not a function return type.

Right now, it doesn't do this for externs yet because there are several places in js/html and hxnodejs that have Promise<Void>. I'm not sure what to do with that right now, but we'll have to figure this out before merging.

I'm deleting the test for #6810 because that depends on typedeffing Void. However, the issue can be closed because it will no longer be relevant.

Edit: I forgot to mention something: We're also adding haxe.NoValue here which can be used instead of Void.

---

Closes #3463
Closes #6810
Closes #11555

[EliteMasterEric]

🎉 for haxe.NoValue!

[Simn]

I'm kind of lying about the "only in return types" part here because there's also still the Void -> ? situation, which doesn't even go through the typeloader (which is why this doesn't break here).

I'm not sure what to do with the old function syntax in general. The new one is objectively superior and I'm generally not a fan of having two ways to express the same thing. On the other hand, is it really worth breaking code over something so idealistic? I think it would take some sort of actual problem to justify this, and I don't remember if there are any.

[EliteMasterEric]

I'd say a major release is definitely as good a time as any to make a breaking change. Previous versions of Haxe will still exist, and if we never make this change, the quality and readability of Haxe code overall will suffer as a result.

[kLabz]

I'd say Void -> Void is fine, and (_:Void) -> Void isn't
Lots of people have been using the former for 10+ years now, and it's not even technically wrong

[Simn]

That's debatable because Void -> ? is not the same as (Void) -> ?, and I think that's the only case where this is true.

[nadako]

Why not remove Void->T in Haxe 5 in favor of ()->T

[Simn]

Yes that's the question I'm asking, but in that case we surely should remove the old function type syntax entirely and not just this special case.

[Simn]

I'm being too hasty with that haxe.NoValue change because it's not actually a NoValue type, but rather a Unit type. Consider this:

class C<A> {
	public function new() {}

	public function invoke(a:A) {}
}

function main() {
	var c = new C<haxe.NoValue>();
	c.invoke(null /* here */);
}

In order to call the invoke function, we need to pass a value at run-time. In that light, I think we need to add a haxe.Unit type (instead?) and use it here.