CLS: advanced return type inlays

[DanilaFe]

Builds on #28885.

I thought -- wouldn't it be super cool to show the return type of proc foo(x) do return x as x.type? Turns out, it's possible!

This PR enables CLS to infer types for generic functions without needing their instantiations. This works best with parametrically polymorphic functions. I've added support for referring to formals (x.type above) and to type queries, including some fairly convoluted cases. I haven't found this to be particularly unstable, but it does lean on some pretty tricky machinery (see below), so I disabled this feature by default.

This works by leveraging the machinery I built up for interface resolution in #26396. Specifically, it leans on Dyno's 'template signature' functionality, which creates a signature for a generic function where generic formals are give unique, concrete "placeholder types". The idea is to resolve a function with this signature and compute its return type. If the return type contains a reference to the placeholder type, and we know that placeholder type was (e.g.) created for a formal, we can replace the placeholder type with formal.type.

Placeholder types are only used in interface resolution in Dyno (making them niche), and resolving placeholder functions has never been done before. This is what makes this approach "tricky", and this is why I disabled it by default.

Honestly, that's mostly it. There was an issue caused by the Resolver re-resolving function formals while resolving a function (even though we've already resolved them while computing the original typed signature). This is a long-standing concern, but seems relatively hard to fix in a principled manner. For this PR, the core issue was that the re-resolution was producing AnyTypes (normal) instead of PlaceholderTypes (unique to template signatures). To address this, add a 'isTemplateSignature' flag to the typed signature struct, and ensure the resolver creates PlaceholderTypes for template signatures.

Testing

• CLS tests

[jabraham17]

nit, this should technically go on the previous PR. But no strong need to change the git history imo

[jabraham17]

this comment doesn't seem necessary

[jabraham17]

A test for weird(x: id?hmm)): hmm?