Clarify IndexSearcher#setTimeout semantics

I read the discussion around the introduction of the `IndexSearcher#setTimeout` in #927 . From that conversation, it was suggested to introduce a global `setTimeout` method, instead of adding a timeout argument to the existing `search` method.

That design has an important consequence: users who want to take advantage of the timeout mechanism need to use one `IndexSearcher` implementation per query, more or less. `QueryTimeoutImpl` follows that same principle as it sets the expiration time in its constructor, meaning that when a search will time out is pre-determined at the time that `setTimeout` is called. There is an additional scenario where one would run multiple queries under the hood to power a single logical query, and would like to apply the same expiration time globally.

I think at the very least we should improve the javadocs around the above expectations to ensure that users understand the implications of using `setTimeout`.

In many applications the searcher is shared among different threads: `setTimeout` makes the timeout mutable without handling any concurrency which seems like a bug. I understand that this may come from the expectation that in order to use the timeout mechanism, the searcher would be used from a single thread, but that is not enforced anywhere. `setTimeout` can be called at anytime, and that may affect already running searches? In situations where a logical search is composed of multiple lucene search operations, these could be parallelized. I would not expect `setTimeout` to be called concurrently (although technically possible) but I thought that we should ensure that all threads see the same value for it?

I also wonder if there is a use-case for setting the timeout more than once to the same searcher, instance it feels like it should be set once and never updated?

All in all, I am wondering if we should make the `queryTimeout` member final and remove the `setTimeout` method. I feel like that'd make expectations clearer, and I'd like feedback to verify that that wouldn't block certain use-cases. An alternative would be to handle concurrency around accessing the mutable queryTimeout member.

Start by reading the IndexSearcher#setTimeout API and QueryTimeoutImpl, along with the discussion in #927. Determine whether the intended outcome is clearer Javadocs, immutable timeout state, or synchronized access; done means the timeout lifecycle and concurrency expectations are explicitly settled and documented.

Written by the indexing model from the issue text.