[Editor UI]: Replace the current View for the core editor UI components

Hi there! the currently used structure of grapesjs is based on leveraging _backbonejs model-view concept_ for implementing the **Virtual Dom** inside the ecosystem of grapesjs. Virtual Dom is a great practice which has a vast area of applications and benefits; but the **downside** of virtual dom is the _actual gap between virtual and actual dom itself_, what this means is that the usage of virtual dom is some sort of **performance sacrifice** in order to achieve the model-view concept which is the already established architecture of grapesjs, react, vue & etc.
based on the real-time nature of grapesjs and its ability to manage thousands of model objects based on each user interaction, there are cases that performance is poorly appreciated on model updates that as it's result there would be no real-time experience for the end user. as an example of this scenario think about calling **addAttributes** for _property changes on a complex component type_ that will be invoked every time the end user provides us with new inputs in the associated trait section; each time that user presses a key, there would be a noticeable delay for the model to updates the attributes of the target component according to the user input.
**my proposal on this matter** is to get rid of virtual dom in the sack of **hyperhtml** that benefits from actual dom that are _bounded to a context object that acts as our current model_. the way hyperhtml is achieving the model-view concept for actual dom is leveraging js native **template literals** and it's _associated chunks and interpolations_. i know this is a very scary taboo for the current implementation :) but i think if grapesjs architecture has been started up with backbone, the sub parts of the ecosystem should not follow the same lead although this is a common implication in the development path of a complex project like grapesjs; _backbone can be really tempting to push developers mind to go with it until the end_, but i am suggesting more flexibility by separating grapesjs into a s**olid core with backbone** and all the other parts leveraging hyperhtml to introduce a more lightweight, performance friendly ecosystem that embraces the future with no fear of performance breakdowns.
i am a very naive developer and please forgive me if i am going wrong with this.
[hyperhtml](https://viperhtml.js.org/hyperhtml/documentation)
cheers.