AssetStorage API extensions

[czyzby]

• Progress tracking.
  • Either as a built-in feature of the AssetStorage (internal counters of scheduled, loaded and failed assets) or an external class that allows to list all assets up front and updates itself via callbacks.
• PolygonRegion loading support.
  • PolygonRegion is a niche asset type loaded by PolygonRegionLoader. The loader does work with AssetStorage out of the box, as it calls AssetManager operations that are unsupported by the storage. Extending the loader and slightly modifying its behavior allows to support this asset type.
• Aliases.
  • It could be quite useful to make it possible to add aliases for asset identifiers. E.g. a texture could be loaded with its original "images/sprites/plane.png" path, but it could be referred to as "plane" throughout the application. Dynamically changing what aliases point to could also make it easy to create applications with multiple themes. For example, "skin" could point to completely different UI assets depending on the application config - changing the alias and reloading a view would be all it takes to change the theme.
• JSON assets loading.
  • Initial version of the AssetStorage supported asynchronous loading and deserialization of JSON files. This feature was stripped during the latest release, as even the basic asset loading functionalities of AssetStorage turned out to be quite a bit of work (Asynchronous coroutines-based asset manager: AssetStorage #258). The existing code can be adapted to the latest version of the storage along with its tests, as it's quite useful for loading game configuration, game data, etc.
• Built-in TMX map loaders.
  • LibGDX provides AtlasTmxMapLoader and TmxMapLoader for TMX map loading. Neither of these is registered by default in AssetManager (nor AssetStorage). We could investigate why the loaders are not included by default, and if there is a way to set sensible defaults for TMX map loading in terms of loaders setup in AssetStorage.
• Better support for cancelling.
  • This is a long shot, as I'm not sure if it can be done without public API changes, but we could introduce better support for cancelling of loading coroutines. Note that this already possible - cancelling of coroutines would have a similar effect to unloading an asset concurrently, as the current loading code already handles such case and will interrupt loading process if it detects that the Deferred was already completed exceptionally.

---

Use this issue if you'd like to make a feature request regarding AssetStorage or review the current API of ktx-assets-async.

See #182 and #258.