Calculate inlay hint tooltips lazily by making use of the resolve request

[Veykril]

We currently generate tooltips for inlay hints eagerly (due to simplicity), ideally we should resolve them lazily if the client supports it since we generate a lot of inlay hints nowadays.

[SomeoneToIgnore]

With #15522 merged, we will get the first iteration on this done: inlay hints' data sent over LSP won't have anything extra needed for hint text display, everything else can be resolved instead (for the corresponding client resolve capabilities).

A few notes on the implementation that raised concerns in the PR:
* implementation uses file_id as a data for resolution to use, so it can re-query a smaller range of the same inlay_hints.rs::inlay_hints query.
A better sanitized option would be to sent file URIs, as LSP does (see textDocument/inlayHint parameters as an example), but that means every inlay hint data field would have an absolute path to its file which bloats the request quite significantly.

Implementation omits data field for hints without the data to resolve, but that does not bring a lot of improvement, rust-analyzer has a lot of locations

* hints are resolved by querying for less range than the original inlay hint request range.
This might lead to issues in the future, with e.g. lifetime hints (currently there's nothing to resolve for them and it's fine) that belong to a certain position, but need to have textDocument/inlayHint query for bigger range.

For now, when resolving a hint, r-a queries nearest ast::BlockExpr or ast::Item ancestor range: #16089

* despite the LSP data not being sent, rust-analyzer still computes all data on the server, just does not send it anymore.
A proper resolution should avoid resolving label parts at least.