First checkin for the implementation of Byte Ranges in Readium SDK (WORK IN PROGRESS)

This is the first checkin for the implementation of Byte Ranges in Readium SDK. In short, the objective of adding Byte Ranges
to Readium SDK is so that there is a way to deal with resources of great size inside an ePUB. For example, you may have an ePUB
file with a 1 GB video file in it, and in that case you want to allow the client app to be able to read just chunks of bytes out of that video,
and not have to put the entire 1 GB video in memory.

This is still a work in progress. There are still code changes that we need to make, plus some more code cleanup that we want to do,
before marking this as concluded. Following checkins will take care of that.
added missing Package API (so I can compile LauncherOSX and test the feature branch)
fixes memory leaks and crashes with FilterData()
Obfuscated fonts: added missing support for application/font-XXX, where XXX may for example be woff, as with the Wasteland EPUB3 IDPF sample)
Fixed FilterChain bug: reading bytes may reach zero-size, added checks to properly EOF
yet another AbsolutePath() BasePath() side-effect, see https://github.com/readium/readium-sdk/issues/91
FIXED obfuscated fonts support for SmokeTestFXL (because the root archive directory is a sibling of META-INF, instead of sub-directory)
enabled supportsRange on font obfuscator, so we can test a real content filter. unforunately the implementation is incomplete, as RangeFilterContext is never instanciated anywhere, and FilterChainSyncStream::ReadBytes/FilterBytes() with the ByteRange parameter are never used anywhere. also, ByteRangeFilterSyncStream::ReadBytes() with the ByteRange parameter invokes FilterData() with null pointer for source buffer data, so obviously it is not going to return anything :)   (as I said, this seems incomplete at this stage...to be continued)
Making sure that RDPackageResource is set to the proper offset when dealing with byte ranges
Merge branch 'develop' into feature/ByteRangeStreams
Checking in the new PassThroughFilter class

This checkin adds the new PassThroughFilter class. This is a very simple class: it just pass along raw bytes without modification. However,
despite its simplicity, it can do a number of things for us:

- It works as a great sample of how to write a ContentFilter, and also one that deals with byte ranges.
- It can be used to debug a stream of bytes, because it can be put in the middle of a filter chain and you can inspect bytes in it.
- It is quite easy to modify, therefore it can be used to write logs about, for example, how often a given resource is read.
- It can be used to debug the ContentFilter mechanism itself.

As I said, feel free to copy and modify this class to do whatever you may need.
Fixing a previous bad merge

Recently, I had to merge the feature/ByteRangeStreams branch with the develop branch. However, I made a small mistake
on SourceTree and actually removed this little change from RDPackageResourceConnection.m. So, this checkin just brings it
back.
Changing the smart pointer for the vector of byte streams

With the changes we recently made on RDPackage, the code now uses SyncContentStreamForItem() (or SyncByteRangeForItem())
in order to get a byte stream for a given resource. The problem, though, is that those methods return a ByteStreamPtr, which was
defined by Jim to be a shared_ptr<ByteStream>. This way, in order to be able to store them in the m_byteStreamVector member
variable, we need to use a shared_ptr instead of a unique_ptr.
Font (de)obfuscation does not support byte range (was set for testing only, but now we have a "pass through" content filter to play with)
addresses comments in https://github.com/readium/readium-sdk/commit/6a791df5b528ba1dc7bf54e0161efdc167d3e366#diff-e019e01a734b083686dba47a2f399bffR1428
(ensure offset is up to date in resource before reading bytes)
fallback to non-byte-range content stream in cases whereby a resource is requested with byte range support, but its filter does not support it (e.g. obfuscated fonts)
Merge branch 'develop' into feature/ByteRangeStreams

Conflicts:
	Platform/Apple/RDServices/Main/RDPackage.mm
	Platform/Apple/RDServices/Main/RDPackageResource.mm
in the process of testing Media Overlays byte range content stream with pass through content filter (not working, as there is missing buffer-fill code at the moment)
added missing code to support byte ranges passing through a compatible filter. commented unused code. to be discussed.
minor change in filter_chain (IsFullRange is satisfactory, no need to expand the range to the passed length)
iOS: working obfuscated fonts with byte range support (fallback to whole stream, but goes through filter via the correct sync-stream)
check for existence of RangeFilterContext on the client side of FilterData (edge case: concrete implementation of Content Filter claims support for ByteRanges but does not have a compatible Context object)
split filter_chain classes into separate files (no renaming yet)