Move UI components to helix-view and keep rendering logic in helix-term

[sudormrfbin]

This PR keeps the rendering logic of components ("widgets") like FilePicker, EditorView, etc in helix-term and moves the structs themselves to helix-view. This is being done with the end goal of separating Compositor out to a trait (see #39 (comment) for why this is necessary) which will unblock the path to a GUI implementation.

The specific design I'm thinking of following is described in #618 (comment). Even if the proposed design (for the end goal for a Compositor trait) is not the best one, I think there is value in separating the rendering logic from everything else. Different frontends will want to do rendering their own way, but we still need to provide a base set of components that the editor will use and the frontends can implement. This PR attempts to move those base components into helix-view and leaves the rendering logic open to implementation (one such implementation will be helix-term, and others will be GUIs in the future).

Note: A single commit will move only a single component so as to make reviewing easier.

[archseer]

I was considering this but I wasn't sure if this is the right approach. Different frontends will likely need to store different data for rendering, for example while a pop-up might have character grid coordinates for term, it would use pixel positions on a skia frontend.

[archseer]

We could make the components associated types on the trait maybe? Compositor::Prompt etc

[sudormrfbin]

Different frontends will likely need to store different data for rendering, for example while a pop-up might have character grid coordinates for term, it would use pixel positions on a skia frontend.

I was thinking of something like this:

// crate helix-gui

use helix_view::ui::Popup; // only the `Popup` struct and it's bare impl
use helix_view::compositor::Component;

struct GuiPopup { // wrapper struct
	inner: Popup,
	// other gui specific data
}

impl GuiPopup {
	fn new(popup: Popup) -> Self { /* ... */ }
	// ...
}

impl Component for GuiPopup { /* ... */ }

Popup will have the row and column on which to render it, and GuiPopup can convert it into pixel positions, store it and use it at render time.

If we were instead to have something akin to associated types on Compositor like Compositor::Popup, each frontend will have to re-implement a lot of component boilerplate that will be common to all frontends, for example scoring the items in a Picker (most of the bare impl blocks on components actually).