Internally distinguish unary/n-ary/async function types

[rossberg]

2 and a half flags on function types.

[nomeata]

These flags are about the calling convention, answering the questions:

• Does the function have an argument of tuple type and actually expects the elements on the stack (n-ary), or does it expect a single argument (unary).
• Does it have a async t return type that is actually implemented by an additional (t -> ()) argument.
• Otherwise, does it have a tuple return type, and actually return the elements separately on the stack (n-ary return) or just returns a single value (unary).

It occurs to me that the async t type could make use of a similar flag: Since it’s calling convention involves an an argument of function type (t -> ()), it should indicate whether the callback is unary or n-ary!

One flag should be enough so: There should be no reason to use a different return convention than n-ary (i.e. 0-ary) to return the empty tuple () the stack.

[nomeata]

At the phone call today, we were touching back on that issue, and we leaned towards the alternative, which is: Tuples become 1½ class, and instantiating a polymorphic type with tuples becomes forbidden. This way, polymorphism doesn’t cause problems here any more, and we know at function declaration and call type which convention to use based on the type (i.e. type variable is always unary).

[nomeata]

Fixed by 4f03117.