HSEARCH-1693 Time based commit for async indexing

https://hibernate.atlassian.net/browse/HSEARCH-1693

Introduced a new abstraction called ```CommitPolicy``` which is responsible for commit handling for the async index scenario (and potentially for the sync case). One of the implementations is ```ScheduledCommitPolicy``` that commits at configured intervals, governed by the property ```"hibernate.search.default.refresh_interval"```

Some perf results for infinispan [1]

10 Threads each putting 100k entities into a cache (total 1M entities)

First three scenarios are what we have currently, when no indexing is enabled (thus no hibernate search involved) and for the current async indexing (worker.execution = async). Last couple of scenarios are with time based commits proposed by this PR.
Tests don't wait until the background indexing finishes, but rather counts the number of indexed entities after the cache.put ends

Scenario  |  load time T (seconds) | docs indexed after T 
----- | ----- | -----
Indexing disabled | 50 | 0
Async Indexing  | 12092 | 549485
Async Indexing (queueSize = 10000) | 11576 | 542795
__Async Commit Interval 500ms__ |  81 | 999699
__Async Commit Interval 1000ms__ |  75 | 999991

[1] https://github.com/infinispan/infinispan/blob/master/query/src/test/java/org/infinispan/query/backend/MergeTest.java

@Sanne please check if the idea of reducing commits for the sync case is compatible with this abstraction

Is property name ```"hibernate.search.default.refresh_interval"``` adequate?  
I think you might need to flush too? Or is someone else taking that into account?
Would be good to have an explicit test for this:
 - start a backend having an extremely high refresh time
 - send a write operation to the backend
 - verify the index change is not visible
 - close the backend
 - verify all changes had been stored
 - verify a