feat(core): add AssetManager::iter

[lucasfernog-crabnebula]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

This new function allows users to iterate on all embedded assets, important if you want to AssetManager::get an asset you are not sure exists.

[amrbashir]

Do we really need the box here? can't we implement InotIterator directly on the type and it construct a new type AssetEntries that is an iterator?

[lucasfernog-crabnebula]

it needs to be dyn because we're in the context of a trait.. so it needs Box too to be sized. Writing another type doesn't help this. It's also the solution used for csp_hashes.

[amrbashir]

If we return an AssetsEntries struct, we don't need to deal with dyn and can just implement Iterator on AssetsEntries

      fn iter<'a>(&'a self) -> AssetsEntries<'a, &'_ str, &'_ [u8]>;

or we can return phf::map::Entries directly

      fn iter<'a>(&'a self) -> phf::map::Entries<'a, &'_ str, &'_ [u8]>;

This should also be done for csp_hashes as well but to avoid breaking changes, we can delay that change to v2

[lucasfernog-crabnebula]

but then the AssetEntries need to hold the iterator anyway, unless we force the type to be a HashMap which isn't a good idea really for a trait

[amrbashir]

The only downside I see with this, is that AssetsEntries will need to use phf::map::Entries as a concrete type under the hood and now the trait Assets is not so generic and that makes me wonder, do we need this trait? seems like our usage of it, could be just replaced with the concrete EmbeddedAssets type

edit: GitHub didn't show me your previous message about the HashMap

[lucasfernog-crabnebula]

for tests it's nice to have this trait

but we can also put the author @chippers on the line

[amrbashir]

this is not a blocker btw, just would be a nice improvement for v2 (unless the trait is really required)

[chippers]

Late on seeing this @amrbashir @lucasfernog-crabnebula , the asset trait allows people to implement their own asset handling, such as if they want to fetch them from disk or network. it's one of the original reasons it became possible to change the items in a Context