rustdoc-search: show type signature on type-driven SERP

[notriddle]

This is a rewrite of #117112, based on feedback by @aDotInTheVoid.

This is a draft because of two known issues:

1. I need to fix it so that it plumbs the real names of user-supplied generics. Right now, the query string is lowercased before it's even parsed. That needs fixed so that we can show the T is t thing correctly.

Preview

Preview page:

• https://notriddle.com/rustdoc-html-demo-11/type-signature-v2/std/index.html?search=vec%3CU%3E%20-%3E%20%5BT%5D
• https://notriddle.com/rustdoc-html-demo-11/type-signature-v2/std/index.html?search=option%3Ct%3E%20-%3E%20result%3Ct%3E

Screenshots:

Rationale

Since the point of this feature is to answer the question "why this a match," it's important that it communicates a few things:

• How do I use this? This UI shows types as Rustdoc sees them, using Rustdoc's search syntax, rather than the syntax used by normal Rust. It's supposed to act as a built-in, context-sensitive tutorial, since you can type a name in, switch to the In Parameters tab, and see what you could've typed to get a particular result.
• Which type parameters got matched to other type parameters? This information is found in a popover that you can open to see information about a search result. This makes the visible type signature a strict dump of the search index, providing reasonably clear separation of user input from output.
• How does the search engine even work, anyway? It's important that this page accurately shows you what unboxing occurred and which mappings got followed. That's why parts of the highlighter are baked into the type unification function: it doesn't just show you where your atoms occur, but actually shows you which ones got matched. A highlighted "where clause" is also found in the About This Result popover.

This change doesn't touch deduplication. That logic needs some adjusting, but is separate enough from this problem to be done in a different PR.

How it works

A particular source of complexity in this PR is caused by storing the names of type parameters. Since this data is only needed after the results come up, loading them gets delayed until after the search is done, so that they can be loaded at the same time as the descriptions.

Future possibilities

This PR is based on #124148. This feature benefits from the type signature index itself being accurate, so we really kinda need full support for Rust's type grammar.

[rustbot]

r? @GuillaumeGomez

rustbot has assigned @GuillaumeGomez.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[GuillaumeGomez]

I'll let @aDotInTheVoid confirms it looks good before reviewing the code.