HSEARCH-3084 Initialize and close index managers / backends in parallel

[yrodiere]

https://hibernate.atlassian.net/browse/HSEARCH-3084

This brings two main changes:

1. On startup, the initialization works (creating/validating ES indexes, creating filesystem directories for Lucene indexes) is now executed in parallel for all indexes.
2. On shutdown, we now stop accepting works for all indexes, then we wait for ongoing works to finish executing. Before this PR, we were stopping and waiting for each index in turn, which would lead to less-than-ideal behavior when multiple indexes share a single work queue (it's the case for Elasticsearch when mass indexing).

I was hoping that item 1 would improve startup performance with Elasticsearch when there are many indexes, since we would create all indexes in parallel instead of one after another, and each creation takes about 200ms, not counting network latency.
It seems I was wrong: when I test with a single-instance ES cluster, there is absolutely no difference, and when I test with a 5-instance cluster (3 masters, 2 replicas) and 8 indexes, it only takes ~25% less time. I'd have expected something like 80% less.

The problem seems to be that Elasticsearch nodes use some sort of global lock when they create indexes, so even if I send many index creations in parallel, they are executed one after another...

I would be inclined to merge this PR anyway, for these reasons:

1. I only tested on the loopback interface (ES running locally and accessed through 127.0.0.1). ES requests other than index creations (get index health, get index settings, ...) are sent, executed, and the response received in about 5ms. Non-loopback network interfaces will definitely show more latency, and in these cases I think sending requests in parallel could improve performance slightly.
2. I think the new design makes more sense, especially on shutdown: the start/pre-stop/stop methods will be useful when we decide to allow starting/stopping index managers at runtime.
3. The BatchingExecutor class is now much simpler.
4. We're a bit closer to being able to use the Lucene backend in Quarkus, since a few filesystem operations are now delayed until the second phase of bootstrap (when Quarkus starts its native image) instead of being executed during the first phase (when Quarkus compiles the application).

[fax4ever]

Great work!
You also improve a lot the existing code!
I've just few marginal doubts on it.

[yrodiere]

Rebased and addressed your comment, thanks!
Waiting for the build to end, then I'll merge.

[yrodiere]

Merged, thanks!