Evaluate <> and provide type resolution in lalrpop.

[dnbln]

Will need to cache the resolved lalrpop types (as of now resolves everything and that can get quite expensive).

Edit: Sorry for the quite big PR. This one has plenty of changes, related to <> expressions and type resolution. I only cached the types of nonterminals where there are no "parameters"; also if you think the variables / functions can have better names I would be more than happy to change them.

With that, this PR is more or less ready for review.

[AzureMarker]

Thanks for working on this! I'll get to work on the review soon.

[dnbln]

Found a weird corner-case in the grammar while testing:

Given this:

X: () = {
}

Y: () = {
}

F = {
    <a: X> Y <Y> => f(<>)
}

The alternative in F has 2 symbols: <a: X> and Y<Y>. Just putting it here because I thought it was weird.

[AzureMarker]

This is really good! I'm excited to see no errors in my grammar files and good type inference. Just a few small things here and there, but congrats on getting this to work!

[AzureMarker]

RE: the odd grammar issue, yeah that's odd. I wonder how LALRPOP handles that itself. After diving into the code, it looks like the lexer emits either a MacroId or a normal Id depending on if there is an < immediately following an identifier (with no space in-between):
https://github.com/lalrpop/lalrpop/blob/cba3a7463c014b8444623848219532628054e9a1/lalrpop/src/tok/mod.rs#L647

Edit: created #19

[AzureMarker]

This looks great! Thanks again for working on this.