Refactor UI

[nic-hartley]

Currently everything's extremely immediate, doing all its rendering right then. This is convenient and fast and easy to implement, but it means that common UI features like scrolling are really hard. I want to rewrite the UI at some point, exposing almost the same API for normal attachments, but a slightly more complex RawAttachment.

The idea is to go from the current pass-input-and-render-all-at-once-recursively model to something more advanced. Not totally sure exactly how it'd work, but the idea is:

• Using the region hierarchy from the last run-through, allocate and handle inputs live during the attach calls
• Store the attachments for rendering and re-layout after all the attaches are complete
• After all the input is distributed and all the attachments are collected, go back through to calculate layout and render

Ideall the Attachment/Region API will stay identical (except that you'll be able to .split(scroll!(...)) to get a scrollable region). RawAttachment will probably have to change -- I'm imagining there'll need to be an fn input(&mut self, Action) -> Self::Output, or maybe a fn input(self, Action) -> (Self::Prepped, Self::Output) to get the input. Then some sort of fn layout(&self, size: XY) -> LayoutRequest/fn render(self, ScreenView), maybe, or maybe just a fn render(self, &mut VirtualScreenView) which provides the real screen size and "returns" the maximum positions that got written to for determining sizes used.

This complexity can probably be reduced to just the parts that really need it? Probably 99% of all the layout done will be totally static; it's only in certain situations in dynamic regions in scrollable regions that we have to worry about wrangling layout externally. Then again, the more advanced approach might be useful for optimizations, e.g. being able to skip the layout/rendering when inputs are flying or processing is lagging, which is something I want to do anyway.