Widget states storage

[alex13sh]

I have been using iced for my projects for a year now. My concern is that the Application::view function is mutable. I don't know, maybe you have your own solution, but I decided to offer my own. I know that you don't like to go to the code without a preliminary discussion, but my English is bad.

This is my first PR not only in this project, but also my first contribution to open source in general. So do not judge strictly.
This PR allows you to get rid of the changeable Application function::view, by storing states in a special WidgetStateStorage struct. This storage is formed during the deletion of the current Element tree and before creating a new Element tree, during the Application::view call. StateStorage is temporarily stored in the Cache and is used inside the UserInterface::builder.
Since widgets themselves store their state, now there is no longer a need to store widget states inside the Application, and therefore there is no need inside the Application::view function to pass a mutable reference to the state.
But what if you need to change the state of some widget inside the Application::update function? Then it is possible to use a mutable reference to StateStorage, which is passed to the argument of the update function.
Each State has its own ID, which is manually specified or automatically generated. To get a mutable reference to the state of a specific widget inside the Application::update function, you must assign an ID to this widget in advance.
A tree of elements of great depth is sometimes divided into several "components", and in this case, an ID conflict may occur. To avoid this, a multi-level ID in the form of PathBuf is used.

Two functions have been added for the widget function. "into_states" - the widget is deleted and returns its state, "apply_status" - the widget finds and assigns its state.

[hecrj]

We talked briefly about this in the last Discord meeting.

In short, there are many challenges here that need discussion:

• The strategy used to identify widgets and keep continuity (specially when the view tree changes)
  • Do we want to burden our users with generating unique identifiers?
  • Do we need a diffing algorithm?
• The changes to the Widget API
  • What is the simplest way to extend it to support the new use cases?
  • How do we store the states of each Widget? Do we really need to box everything and downcast?
• Impact on other features
  • How do the changes relate to other future planned features (e.g. persistent widget tree [RFC] Thoughts on a persistent widget tree #553).

I think we need to answer these questions first before we jump into writing code. @derezzedex is already looking into it! Feel free to join the Discord server and chat about it.