DataSource refactoring

[hjanetzek]

This PR adds the RawDataSource interface to enable chaining of tile data fetching.

struct RawDataSource {
    virtual bool loadTileData(std::shared_ptr<TileTask> _task, TileTaskCb _cb);
...
    void setNext(std::unique_ptr<RawDataSource> _next) {
        next = std::move(_next);
        next->level = level + 1;
    }
    std::unique_ptr<RawDataSource> next;
    int level = 0;
}

A DataSource holds a chain of RawDataSources. On a tile request loadTileData is called on the first RawDataSource, if it can't serve the tile data the request is passed on to the next source. The task is passed back through the chain via the TileTaskCb. This allows earlier sources to intercept the result e.g. for caching by passing their own TileTaskCb.

The in-memory cache and tile download steps are moved out of DataSource and now implemented as RawDataSources.

[tallytalwar]

We might need another class for non tiled network data sources. As an MBTile source could be downloaded, or in future our own mapzen "zipped" source could be downloaded.

[hjanetzek]

Downloading bundles should be handled separately in my opinion, similar to what we do in ClientGeoJson source, or become part of scene loading.

[hjanetzek]

Downloads of huge MBTiles packs needs some more thought. Bundles should be stored on disk to not download a few hundred MB each time. Also better ask for user feedback before downloading when they are on mobile data ;)

[bcamper]

I think that run-time download of new tile bundles is something that should be handled by a Mapzen platform SDK (Android or iOS) rather than in Tangram core.

[tallytalwar]

I agree download of the bundles should be handled by the platform SDK.

I was mainly asking about about where does it fit in this new rawdata chaining architecture.

[matteblair]

Looks great! I'm good with merging this.