Add UI to help with advanced search requests

[GuillaumeGomez]

Part of #99321.

This is for now a very early POC. The idea would be to provide help writing search requests for more advanced ones because the syntax might not be obvious for everyone.

Here what it currently looks like:

You can test it here.

To be noted: the "advanced search helper" appears when search.js is loaded, so when you focused on the search input or when you directly arrive on a search results page.

r? @rust-lang/rustdoc

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

configure: rust.debug-assertions := True
configure: rust.overflow-checks := True
configure: llvm.assertions      := True
configure: dist.missing-tools   := True
configure: build.configure-args := ['--enable-sccache', '--disable-manage-submodu ...
configure: writing `config.toml` in current directory
configure: 
configure: run `python /checkout/x.py --help`
Attempting with retry: make prepare
---
tidy: Skipping binary file check, read-only filesystem
Checking which error codes lack tests...
* 631 error codes
* highest error code: E0789
tidy error: /checkout/src/librustdoc/html/static/css/rustdoc.css:1019: line longer than 100 chars
Found 0 error(s) in error codes
Done!
* 379 features
some tidy checks failed

[GuillaumeGomez]

@sdroege gave me an interesting take about this:

what i usually need are identifier searches or "give me functions that handle arguments of this type" or "... return this type"

With this in mind, instead of having a very generic form, we'd have smaller specialized ones:

1. literal search (in item name, in arguments or in returned)
2. signature search
   1. have arguments of this type
   2. return this type
   3. potentially both

[Manishearth]

I wonder if this should be in a modal dialog instead. The styling of the form could probably be improved as well

But I think this is a good start!

[GuillaumeGomez]

This is really a starting point. I really hope the final UI won't look like this because it's a mess. Way too complicated to use and not obvious and the users from the feedback I got. So a lot of work remains to be done in any case. :)

A modal dialog could be an interesting approach too. Do you have some idea why it would better btw?

[Manishearth]

I find that they can be made more dynamic and it's more annoying when the location of the search results is pushed to the bottom

[GuillaumeGomez]

All good points! A modal would also simplify a bit the DOM since it wouldn't have to take of the "surroundings".

[notriddle]

The really big thing that needs dealt with is that enum:Result, FnOnce -> bool tags the enum onto the first parameter, not the entire query. This makes sense, because, by definition, this query can only match functions.

The UI makes it look like it affects the whole query, which is wrong.

[bors]

☔ The latest upstream changes (presumably #99058) made this pull request unmergeable. Please resolve the merge conflicts.

[camelid]

What about using T and U since they're more common names for generics?

Suggested change

	<input placeholder="gen1, gen2, gen3..." class="generic">
	<input placeholder="T, U, ..." class="generic">

[camelid]

I think "function" covers both.

Suggested change

	<input placeholder="function/method arguments" class="arg">
	<input placeholder="function arguments" class="arg">

[camelid]

Ditto.

Suggested change

	<input placeholder="gen1, gen2, gen3..." class="generic">
	<input placeholder="T, U, ..." class="generic">