Concurrent byte and int block implementations [LUCENE-2575]

The current \*BlockPool implementations aren't quite concurrent.
We really need something that has a locking flush method, where
flush is called at the end of adding a document. Once flushed,
the newly written data would be available to all other reading
threads (ie, postings etc). I'm not sure I understand the slices
concept, it seems like it'd be easier to implement a seekable
random access file like API. One'd seek to a given position,
then read or write from there. The underlying management of byte
arrays could then be hidden?

---
Migrated from [LUCENE-2575](https://issues.apache.org/jira/browse/LUCENE-2575) by Jason Rutherglen, updated May 09 2016
Attachments: [LUCENE-2575.patch](https://apache.github.io/lucene-jira-archive/attachments/LUCENE-2575/LUCENE-2575.patch) (versions: 8)
Linked issues:
- #3641
- #3388

Start by reading the issue body, the attached LUCENE-2575.patch, and linked issues #3641 and #3388 to understand the existing BlockPool and slices design. Done means concurrent byte and int block implementations provide a locking flush at document completion and make newly flushed data visible to reader threads.

Written by the indexing model from the issue text.