Make parameter names in function types optional

[HurryStarfish]

Assume we have the following functions:

Function Add:Int(summand1:Int, summand2:Int)
	Return summand1 * summand2
End Function

Function Multiply:Int(factor1:Int, factor2:Int)
	Return factor1 * factor2
End Function

When we define a function (or method), we are, of course, forced to name our parameters. Otherwise we wouldn't be able to refer to them inside the function body.

But when function types are used anywhere else, this does not make as much sense: Local func:Int(number1:Int, number2:Int) We can assign both Add and Multiply (and possibly a ton of other functions) to this variable, so we cannot give the parameters very meaningful names. We don't really care about these names anyway, because we are never gonna do anything with them. So instead of being forced to write "dummy" names for the variable declaration, it would be nice if the parameter names were optional: Local func:Int(Int, Int)

The same applies when a function type is used to bind a type parameter. For example, if we wanted to store all our math functions in a collection, then Local mathFuncs:ICollection<Int(Int, Int)> looks more readable than Local mathFuncs:ICollection<Int(number1:Int, number2:Int)>

To preserve compatibility with legacy BlitzMax, specifying the names should still be allowed, just not required. This will also allow the user to specify them in cases where they are useful as a form of documentation.

There is one potential problem:

Function Outer(inner())
	' ...
End Function

Local func(inner()) = Outer

Here, we have the function Outer, which takes another function as a parameter. We call that parameter inner. We can now declare a variable like this: a) Local func(inner()) = Outer or alternatively, if we leave out the now-optional parameter name, like this: b) Local func(()) = Outer This might look a bit unusual at first, but it's perfectly fine. The problem is that version a) is ambiguous, because inner() can either mean "a parameter named inner which has the type ()" or "an unnamed parameter which has the type inner()". This should not really be an issue in practice, because it only matters in the improbable case that inner exists as a type (whereas user-defined types are prefixed with T, I or S by convention), but the compiler needs to be able to handle it somehow. Maybe a compile error could simply be raised if someone tries to declare a parameter that has the same name as an existing type.