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
HSEARCH-472 Isolate EntityIndexBinder creation in a factory
HSEARCH-472 Prepare IndexManagerHolder for dynamic sharding
HSEARCH-472 Split MutableEntityIndexBinding into interface / implementation
HSEARCH-472 Implement dynamic sharding strategy and introduce ShardIndentifierProvider
HSEARCH-472 Import reordering / cleanup
HSEARCH-472 Make IndexManagerHolder offer the ability to add IndexManagers lazily
HSEARCH-472 IndexManager creation: reduce contention by doing a lookup before entering the synchronized structure
HSEARCH-472 Do not use AssertionFailure
HSEARCH-472 Add some comment to the code about dynamic shards being eagerly loaded at SF creation
HSEARCH-472 Remove appending logic of indexName and shard identifier
HSEARCH-472 Make sure to associate the SearchFactory to the IndexManager created late
HSEARCH-472 Add tests for dynamic sharding
HSEARCH-472 Move Logger ids after rebase
HSEARCH-472 Move files to new directory structure
HSEARCH-472 Fix checkstyle violations
HSEARCH-472 Change isDynamicSharding to isShardingDynamic