Redesign `rust-analyzer::flycheck`

The current implementation of flycheck is flawed in that it instantiates at most a single "flycheck instance" for each workspace. With the introduction of rust-analyzer.toml files, more fine-grained configuration has become possible. Therefore, we need more flexibility in flycheck instances. At the same time, we want to avoid having many `flycheck' threads, as this is clearly inefficient.

Another issue that also needs to be addressed is how hard it is to test any kind of flycheck activity. The new model should make testing less of a problem for us.

Some key points about the new approach

A thread pool will be used to avoid unnecessary initialization/destruction of threads. The number of threads will be configurable.
Threads are used to execute whatever flycheck op is waiting to be executed. To map the results of a flycheck' instance to the corresponding workspace, it was previously sufficient to keep aworkspace id'. The new model could use a hash of workspace_id * target * other things I can't think of to compute an id.
More points to come in the next few days.

Dumping some quick notes/thoughts:

Current architecture:

"spawn" one flycheck worker per loaded workspace, we eagerly built the command at this stage
- the command building should likely be deferred instead, as we want it to be dynamic according to our needs (see https://github.com/rust-lang/rust-analyzer/issues/14205)
on initial project load finishing, instruct all workers to check their full workspace
Whenever a file is saved
- figure out which crates the file belongs to
  - then, instruct all flycheck workers of workspaces that contain any of the crates to flycheck either:
    - the relevant package belonging to the crate (if the workspace c onfig is not set)
    - or the full workspace otherwise
- if no flycheck was triggered, isntruct all workers to check their full workspace

Notably, this has the downside that we can only check a single package (or target even) per workspace. We also can bring down the system if there are a lot of workspaces and we check all of them at once.

Also, we do want to keep the property of having at most one flycheck worker run for a given workspace (multiple is non-sensical as they will block on another for the cargo lock anyways).

So maybe a job queue isn't actually needed and we can keep the per workspace workers, from the looks of it we mainly need to make them more flexible wrt. the command they invoke?

some relevant issues to consider:

rust-lang / rust-analyzer

Redesign `rust-analyzer::flycheck` #18186