HSEARCH-1725 Improve allocation rate of the new Lucene synchronous batch backend


When testing low-scale I couldn't detect any performance improvement, still this has a lower contention point on the work queue and keeps the allocation rate of objects much lower.

Also improves the allocation rate for the garbage created by the `ErrorHandler`, at cost of being slightly less efficient in the case there actually is an error (which is hopefully a great bargain).

 - https://hibernate.atlassian.net/browse/HSEARCH-1725

Using the `LinkedBlockingDeque` was semantically correct but the wrong choice from performance point of view.

It could be considered similar to buffering an inpustream, and then pass it to a stream which buffers again.. it will work fine but it's still considered a bug from a performance point of view.
Now consider that the work of the `Consumer` thread is extremely hot: we now have a single thread responsible for all writes of the index, and not just for the current JVM but as master for a cluster: this lock acquisition needs to be efficient.
So I wouldn't bother to tune anything which isn't "hot" at runtime: this one is extremely hot and deserves some attention.

The main difference with the `LinkedBlockingDeque` is that this structure we're using now doesn't block at all, as we already control flow in the `BatchSyncProcessor` by explicitly parking threads.

The second significant advantage of this approach is that the code in `Consumer` (as it was before the patch) needed to perform an _isEmpty()_ twice before doing a successful drain, so each commit batch needed to acquire the locks of the structure three times. This is now only one lock, as the drain is atomic and incorporates the check for emptyness in the same lock.
Consider that this lock will be contented with all work producing threads, and none will make progress unless the Consumer threads can work efficiently, so locking there really stands in the way of progress for the whole system.

Also this one allows us to do an atomic drain of the queue without doing collections copies, without allocating arrays, and minimizing the time it needs to own the lock.