This is needed because during a remodel we need to use a different store with a store context with the new model information etc.
This reworks snapstate.Store instead of relying solely on DeviceContext, because:
* less code churn
* conceptually we can talk to the store to some limited extent even without a model or being registered
This introduces also Install/UpdateUnderDeviceContext to use in the upcoming remodel planning task when there is a brand store/brand/model change. Given the very specific use case it didn't make sense to expand the signatures of Install/Update directly, also *UnderDeviceContext later will need to take a change id to do the right thing vs conflict checks.
The "Under" names are not definitive, might use "With" instead.
overlord,overlord/devicestate: do without GadgetInfo/KernelInfo in devicestate
This is mostly achieved by using the fact that we know the name of the gadget snap from the model and by introducing instead a snapstate.HasSnapOfType.
As a drive-by this also simplifies a bit the triggering logic for registration.
