Increase default `rust-analyzer.numThreads` for user experience related to R-A server hangs or solve it in a better way.

Problem

rust-analyzer uses num_cpu cores as default to initialize task thread pool. As for some user like me who has fewer cpu cores (I am using mac which only has 6 cores), rust-analyzer server will easily hang up because small thread size. Here is an example I 'inject' some hover ops to fill up the task thread completely, then I cannot use goto definition any more:

https://github.com/rust-lang/rust-analyzer/assets/14040068/09c40a1d-9901-41d7-801d-2ff864746b5f

Here is an another example:
When someone include!ed a big generated file(>100k loc, which will take up to 100s to diagnose), considering rust-analyzer implementation now, whenever open a new file, it will send all active window to diagnostics. If a fileA which calls include!(some large generated file)is in active window, whenever you open a new file, R-A will resend diagnostics fileA command to task pool. Because it takes 100s+ to process, so in 100s, you opened 6 file, you will hang R-A server up.

Possible Solution

• Increase default rust-analyzer.numThreads to reduce the possibility of hang up entire R-A server. (The easiest way, and will work for most condition)
• Only send newly opened file for diagnostics.
• Redesign task pool. Whenever we are sure a task is definitely be blocked(eg. diagnostics on same file, waiting for salsa's RwLock), we send this task to a separate task pool(which has a large number of thread).

Start by tracing the rust-analyzer.numThreads setting and the task-pool handling described in the issue. Compare the proposed default change, diagnostic scheduling change, and separate task-pool redesign; done requires an agreed approach that prevents long-running work from hanging interactive operations, with regression coverage for the reported scenarios.