Provide a recommended Executor implementation for concurrent search

### Description

Currently, IndexSearcher accepts an executor and doesn't give guidelines about the expected behavior of the executor. I think it would help users if we had a recommended executor for concurrent search. I think it needs the following properties:

### Fixed number of threads

I don't think it makes sense to use a cached threadpool for this use-case.

### Run tasks in the current thread when already in the threadpool

As we're making more things concurrent (`collection`, `rewrite`, `createWeight`) it's becoming increasingly likely to create deadlocks, e.g. by calling `createWeight` from a collector and a fixed number of threads. Our testing framework does this for instance. We could protect from this scenario by running tasks in the current thread when executing from a thread of the thread pool.

### Empty queue, blocking submission and no rejections

Given how we use this executor for fork/join, we don't need an actual queue and could use a `SynchronousQueue`, plus submission should wait until a thread is free instead of rejecting.

One assumption I am making here is that we would want to always run tasks in the executor rather than in the current thread, as this makes it easier to reason about the number of threads that can contribute to search. This is not how it works today, e.g. we run the last slice in the current thread, so we'd have to change this.

Start at IndexSearcher, which accepts the executor, and trace how concurrent search submits work and handles the final slice. Compare the behavior with the requested fixed thread count, current-thread execution within the pool, synchronous submission, blocking, and no rejections. Done means a recommended executor is defined and its behavior is covered for these concurrency cases.

Written by the indexing model from the issue text.