Pass information to apps about already inserted hexpansions

[npentrel]

Currently apps need to loop over the hexpansion slots to see if hexpansions are present or users need to reinsert hexpansions for them to fire an insertion event.

I suggest we pass information about currently inserted hexpansions to app objects on init to avoid these loops.

[gsuberland]

Would it make more sense to provide an API through which the app can query the currently installed hexpansions whenever it likes? That way the app isn't limited to a snapshot of this information only on startup, and could re-request the info after an unplug or plugin event. The firmware itself could handle the task of searching for hexpansions and figuring out what's there, keeping a live registry of hexpansion data, then pass that back up the stack to avoid needing unnecessary I2C scans and re-implementations of the scanning code.

[MatthewWilkes]

I'd agree with @gsuberland, having a way of getting a mapping of slots to headers feels more flexible than adding more things to init. Otherwise users will have to keep it up to date with hexpansion insert/removal event handlers.

[npentrel]

That also sounds good

[walkerdanny]

Have been playing with this here. I've taken the easiest path of extending the HexpansionManagerApp to keep an updated dictionary of hexpansion headers, and added a few methods to make accessing it simpler. This seemed like the most straightforward way of doing things since the HexpansionManagerApp is already responding to insertion/removal events.

There's also a function added to system.hexpansion.util to grab the running HexpansionManagerApp from the scheduler so it can be accessed in an app easily.

Thoughts appreciated, there might be a much better way of doing this!