ECS: re-implement mesh rendering in database entries

[kzsh]

In the first few commits, this was close to a copy/paste from MeshRenderSystem::render3D to GuiRotatingModelView::onDraw. If duplicating the rendering pipeline in these two places is sufficient, I'm happy to simplify this PR back down to that.

That said, the rest of the work is an attempt at re-using some of the code between render3D and onDraw without compromising the clarity of the render system to serve the one-off needs of onDraw. I will admit that the likelihood of render code changing often is pretty low, so maybe this kind of re-use isn't that critical here.

Aside: Again, I'm pretty new to C++, so I'm open to thoughtful feedback on language features I'm misusing, or weaknesses I might be inadvertently introducing, or patterns that make more sense than what I've put in.

I've opted to save the debug work for a separate PR to keep this one a bit smaller, but I did leave one piece from my exploration there in this series of commits 2d0405c. I think it'll be useful to have an entity in order to enumerate and render emitters.

[daid]

maybe it would be possible to use glm::vec3 instead? Not sure if you can initialize a glm::vec3 from a float[3].

But then it would look something like:

glm::vec3 sum{};
for(auto vertex : vertices) sum += glm::vec3(vertex.position);
auto average = sum / float(vertices.size());

for(auto vertex : vertices) {
    float distance = glm::length(glm::vec3(vertex.position) - average);
    ...
}

[daid]

(changing the Mesh float[3] into a glm::vec3 in theory should be possible, but right now feels quite risky and too large of a change)

[kzsh]

I like that idea! That's where I started before changing it to try to match the style of the code above it, but I think it would be cleaner with glm structures/functions.