Replace Map with IMap on AssetCache

[EliteMasterEric]

This allows audio, font, and image to be replaced with any object which implements IMap, which includes custom map implementations with different underlying behavior. This is required to replace the map with a different class, as I don't believe you can extend the standard Map class since it is an abstract and the underlying implementation is provided by the standard library.

In my use case, I am replacing Map with a CallbackMap class I made, which re-implements the standard Map but allows me to register callbacks when values are added or removed.

[dimensionscape]

Hey @EliteMasterEric, thanks again for the PR and the interesting approach.

I just want to clarify something, since I think this comes down to intent.

If the goal here is to hook into internal set() or get() calls made by Lime/OpenFL itself (e.g., tracking when assets are added or retrieved from AssetCache internally), then switching to IMap isn’t a reliable or maintainable way to do that. It introduces risks around platform behavior, weakens the API contract, and relies on assumptions about how Lime uses the map internally (which could change or be replaced at any time).

If instead you're trying to hook into map access or mutations from your own code, then that can be done cleanly today using:

An abstract over Map<K, V> that wraps the returned map from Lime and adds your custom get()/set() logic

Static extension methods for more readable external hooks (e.g., MapHooks.setWithLog(map, key, value))

These options let you customize behavior without needing any changes in Lime itself, and without sacrificing type safety or platform consistency.

So unless Lime/OpenFL explicitly adds support for cache-level hooks (like onAssetSet()), I'd rather avoid changing the API to accept IMap, since it opens the door to subtle bugs without a clear gain for the majority of users.

Let me know if I misunderstood your intent. Happy to discuss further!