HSEARCH-1317 Optimize tail recursion in NRT IndexReader reopening
HSEARCH-1317 Boosting performance: removing contention between writers and readers

Visibility of changes are guaranteed by the volatile flush mentioned in the code comments; now on to why the writes on these different state flags and counters is ok to not be fully atomic.
Initially I considered moving all state in a little valueobject to be replaced atomically, but this:
 - is more complex to replace than a simple CAS operation as there are counter increments involved
 - this level of consistency is not needed

Considering there is commonly [1] just one thread invoking this, this is basically a CAS operation with a value object.

Why is this level of consistency not needed?
* On counters: they grow monotonically and all what the readers care is to not see a value which flags their state as "outdated"
* On in-flight flags: worst case some state (either deletes or writes) is flushed which wasn't strictly required to be flushed yet - but still this is welcome as this state would need to be flushed very soon: it will be a requirement at the next refresh operation, so in practice if we're ready to include those changes as well in the same IO operation now, it's better to do it all in one go as the worst case scenario (the race condition) is beneficial for performance as it allows us to skip some IO.

Note that this is tested by the existing test org.hibernate.search.test.performance.nrt.ReadWriteParallelismTest: it effectively isolates this component to put a lot of contention on this structure, and does validation of correct state being visible.

[1] Only whan a MassIndexer is running we might have parallel invocations of the setupNewReadersRequirements() method.
HSEARCH-1307 Resolve race condition on closing IndexReader still being used for queries
HSEARCH-1317 Javadoc and comments update/clarification