fix: Output checked type in getSelectionTypeOrKind if none is synthed

[georgefst]

This fixes an issue when using this functionality in our frontend to display the type of the currently-selected node: the fallback trivialTree was displayed for nodes in checkable positions (lambdas, constructors).

@brprice would be better placed than I am to explain why we originally ignored this part of the typecache in #1050, or whether this is quite the right approach. But in his absence, and with the Zurihac push, I'd suggest we merge this anyway. I doubt there are any serious downsides.

[dhess]

This does improve things, but holes (empty & non-empty) still return the "trivial tree" with this change. Clearly the typechecker knows the proper type of holes because we can return the appropriate action options etc in other API calls, but there's just something not quite right in the getSelectionTypeOrKind implementation.

Anyway, let's merge it and we'll revisit when we have a chance.

[brprice]

@brprice would be better placed than I am to explain why we originally ignored this part of the typecache in #1050, or whether this is quite the right approach.

I think it was a combination of

• thinking that maybe the correct thing to do was to report both, but the api only had room for one (and UI for two is somewhat unclear), and the synthed is perhaps a better notion of "what type does this node have" than the checked if both are available (though this is not a well-thought-through statement)
• an oversight

[brprice]

This does improve things, but holes (empty & non-empty) still return the "trivial tree" with this change. Clearly the typechecker knows the proper type of holes because we can return the appropriate action options etc in other API calls, but there's just something not quite right in the getSelectionTypeOrKind implementation.

Anyway, let's merge it and we'll revisit when we have a chance.

See #1068