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?  
There is a risk factor here: the contract of _scheduleAtFixedRate_ specifies that "If any execution of the task encounters an exception, subsequent executions are suppressed."

So:
 - can we catch eventual exceptions in the timer layer and delegate them to the registered `org.hibernate.search.exception.ErrorHandler`
 - can we make sure commits will happen even after an exception? Or should we log exception at "Fatal" like level?