[Optimization] Reduce unnecessary Component rebuilds

[nicksenger]

The current implementation of Component results in many unnecessary rebuilds when components are nested inside the view of other components. This can be observed in the following example, with several layers of nested components (code):

unoptimized.mov

This PR optimizes Component to avoid unnecessary rebuilds, after which running the same example results in:

optimized.mov

The cause of excessive rebuilding in the existing implementation is that the component's underlying element is rebuilt eagerly after any potential state mutation. If the component returns a message from update, processing that message at a parent component (or the root application level), will in turn cause another rebuild of the component just built. As a result, with increasing layers of components, the runtime of processing an event which propagates to the root of the application increases in a non-linear fashion.

By deferring rebuild until any widget method is invoked where the latest element is actually required, we can perform this same process in linear time.

If the rebuild is to be deferred until absolutely necessary, invocation of any widget method may require rebuilding of the component's element, and in turn requires diffing of that element's widget sub-tree. This means that mutable access to the element's widget sub-tree is required during every widget method. To achieve this, the widget tree for the component's contained element is moved inside of the component-widget's state and put inside a RefCell. Since width, height and layout do not have even immutable access to the widget tree, but may still be invoked and require rebuilding of the element, an Rc is used to store a reference to the sub-tree on the component-widget instance itself, and populated during diffing (similar to the approach used in the Lazy widget). This allows mutable access to the element's widget tree from any widget method without altering the Widget interface.

For overlay, the contained element's widget sub-tree is moved onto the overlay element, and restored during the overlay's drop (again, similar to how overlay works in the Lazy widget).

This implementation has been tested in a relatively large real-world application having many layers of components both inside & outside overlays. No issues or discrepancies from the current implementation of Component have yet been identified.

[hecrj]

Clever! The lazy crate is getting quite insane. Hopefully we can identify a pattern at some point.

Also, I would generally recommend to avoid nesting Component. A custom widget may work better for containers.