Turns out to be slightly problematic as `(int, int)` could be logically
thought of as an expression evaluating to a tuple value containing
two typedesc[int]s.
To disambiguate, the zero-tuple's type must still be written as
`tuple[]`, and what would be tuple value expressions containing only
typedescs are interpreted as types.
() # value of type `tuple[]`
(int, int) # tuple type
(int, int, ()) # value of type `(typedesc[int], typedesc[int], tuple[])`
The compiler hangs were caused by the interaction of tyError and the instantiation caches.
For procs, the cache wasn't able to find previously compiled proc featuring tyError in the signature.
For types, the unresolved type parameters leading to tyError were not replaced everywhere leading
to endless replaceTypeVarsT recursion for cyclic types.
The fix is still not perfect, because the handling of tyError in other places in the compiler doesn't seem
to be complete and the first test case now results in internal error (still, much better than a hang blocking
your IDE).
Previously, generic types originating from the same body symbol were compared
structurally. The bug illustrates a case, where such a comparison is not correct.
The new approach follows the established method used in typeRel.
This also provides the initial steps towards support for type class "filtered" type inference
fixes an "ordinal type expected" ICE, related to the use of static params
