This is way nicer than the Syntect API, is quite fast, and is also
actually up to date.

It basically doesn’t do what I want, unfortunately, because `minijinja`
needs the underlying type to implement `Serialize` if this is going to
work:

use minijinja::{Environment, Error};
use serde::Serialize;

pub(crate) trait Component: Serialize + Sized {
const VIEW_NAME: &'static str;

fn view(&self, env: &Environment) -> Result<String, Error> {
env.get_template(&Self::template())?.render(self)
}

fn template() -> String {
format!("components/{}.jinja", Self::VIEW_NAME)
}
}

The key bit is that `.render(self)`: it will *only* work if `self` there
has the `Serialize` constraint on it, because that’s how `mininjinja`
currently approaches things. (Future versions might not have that issue,
but future versions are not today.) I still like the idea, but as things
stand today, the result is that if you invoke an item that implements
`Serialize` but does *not* implement `Object` (and, for my purposes,
specifically `Object::call` as a way of invoking `Component::view`), you
get the “native” `Serialize` implementation instead. Which is fine for
how people generally use this, but doesn’t afford the “component” model
I was reaching for. Alas.

I’ll need to rethink this.

I will follow this with updates to the layout of templates as well:
these are really what I had done with “components” historically via
macros.

Instead of having a `view::template_for(view: impl View)` with internal
type shenanigans to support it, just use `Self::template()` relying on
the types that are *necessarily* available to support that via a default
`impl` for `View::template`. Works much nicer.