Resource streams improved: Filter chain hooks, byte range support

This allows for support of:
- Obfuscated fonts (https://github.com/readium/SDKLauncher-Android/issues/44)
- HTTP range requests (https://github.com/readium/SDKLauncher-Android/issues/29)

This fixes the following issues:
#132 - Reading filter chain aware byte streams should be more clear now (PackageResource helper class)
#103 - This is fixed for non filter chain byte streams (now called raw input streams)

Potentially fixes https://github.com/readium/SDKLauncher-Android/issues/22
Just to highlight a fundamental difference between the Android and iOS / OSX launchers (at this stage of ), which we may need to take into consideration when looking into LCP or other DRM encryption schemes.

Right now, the NanoHTTP server pulls binary data from the response's input stream into 16kB buffers:
https://github.com/readium/SDKLauncher-Android/blob/develop/SDKLauncher-Android/src/fi/iki/elonen/NanoHTTPD.java#L622
```
int BUFFER_SIZE = 16 * 1024;
byte[] buff = new byte[BUFFER_SIZE];
while (pending > 0) {
    int read = data.read(buff, 0, ((pending > BUFFER_SIZE) ? BUFFER_SIZE : pending));
    if (read <= 0) {
        break;
    }
    outputStream.write(buff, 0, read);

    pending -= read;
}
```
In iOS and OSX, CocoaHTTPServer also feeds HTTP response bytes into its underlying socket (using 256kB or 512kB buffers, depending on the platform), however this is directly correlated to the size of data chunks that incrementally pass through a non-cached Content Filter (filterData() method). For example, an encrypted image file is typically not requested by WebView via HTTP byte-range (just a regular HTTP request), but the actual byte packets would still be fragmented into distinct consecutive chunks (thus why a decryption algorithm must track its state (previous blocks, etc.)).
I see that in the current Android implementation, this correlation is non-existent, because the input stream is initialised with an intermediary pre-fetched byte buffer that represents the full resource:
https://github.com/readium/SDKLauncher-Android/blob/feature/obfuscatedFonts/SDKLauncher-Android/src/org/readium/sdk/android/launcher/util/EpubServer.java#L182
```
byte[] data = packageResource.readDataFull();
res = new Response(Response.Status.OK, mime, new ByteArrayInputStream(data));
```
Note that even an HTTP byte-range request fetches the full queried data before passing it into a stream:
https://github.com/readium/SDKLauncher-Android/blob/feature/obfuscatedFonts/SDKLauncher-Android/src/org/readium/sdk/android/launcher/util/EpubServer.java#L177
```
 byte[] data = packageResource.readDataOfLength((int) newLen, (int) startFrom);
res = new Response(Response.Status.PARTIAL_CONTENT, mime, new ByteArrayInputStream(data));
```

Behind the scenes, the `ResourceStream` is indeed initialised with `BUFFER_SIZE`, which informs the rate of transfer from the underlying Readium SDK byte stream (which could potentially be bound to a Content Filter filterData()):
https://github.com/readium/readium-sdk/blob/feature/AndroidByteRangeStream/Platform/Android/jni/resource_stream.cpp#L133
```
std::size_t bytesRead = byteStream->ReadBytes(&tmpBuffer, readLength);
```
(see `readLength` = `stream-> getBufferSize()`)


To conclude, this design is totally fine for now. In a future iteration, we might want (or not) to consider an alternative to the aforementioned `ByteArrayInputStream`, for example a "real" stream that would pull data incrementally from the underlying Readium SDK byte stream, thereby avoiding the intermediary `byte[]` full/range buffer prefetching, and correlating more directly with the 16kB buffer that the HTTP server uses. At any rate, I feel that the 4kB buffer is a bit small, and may be suboptimal with some encryption schemes.