feat(uip-editor): store editor state

[fshovchko]

Closes: #617

[ala-n]

There is a mixed responsibility issue in the current implementation:
UIPEditor is not a state-holder and should not interact with storage/modal (the actual state-holder) unless it's directly connected with user interaction.
Consider rework of EditorStore integration considering the following points:

1. It should observe UIPModel directly or be integrated inside model and core
   1.2) Just in case there is a possibility to observe the actual initiator of change inside the core.
2. Please be aware, that the initial state depends on setting it up inside the core. The editor store is only one of the sources, there is also an anchor and default snippet used as a source. The new logic should be in sync with them in terms of priority and execution time. The UIP should not be affected by extra update events as well.

[ala-n]

There are three small but critical points to accept this feature:

1. As a consumer (Dev) I should be able to disable the feature
2. As a user I expect to have a saved state for the exact playground instance (it will be very inconvenient if I found an example of lately opened component A when I open a page for component B that utilizes UIP as well)
3. As a user (without deep knowledge) I should be able to reset to the snippet state (especially when there is no uip-snippet plugin)

To resolve mentioned problems I recommend the following action items:

1. Rework model to use store ONLY IF the store-key declared on uip-root
2. The store uses key store-key to identify the instance (it prewets any inconsistent sharing of the state)
3. (Optional) We can propose a special keyword for user (e.g. PAGE) to use current full page pass to be used as a store key
4. TECH NOTE: the exact browser storage root key should still be identified with uip- prefix
5. Implement a reset button (for the plugin heading section) available for the editor plugin