Visual component should be fine without a constructor

In fact ALL components should be fine just initializing the zero-value
version. This mesh code will be moved into a Mesh class, or something
similar, which will talk with the renderer to ensure it will display
properly.
Components have Types and Entities keep bitwise lists of those Types
EntityDB will be the main holder of all things Entity

It keeps track of the list of known entities and can be given listeners
who will do appropriate processing of entities that match the set of
Components said listener asks for.
Start formalizing definition of "Behavior"

A behavior can initialize a new Entity, update according to the game
tick, and will do more related things.
Set up an entityDB and behaviors on game start
Wrap the listener-specific entity list in a struct

Can't just pass around a slice because as soon as append() is called on
that slice the underlying array can change, rendering all other pointers
obsolute. This way we pass around a pointer to a struct, which then
holds the array, letting references always work.
Re-hook up Graphical behavior to the game

Also changed to a go-style constructor instead of custom object method.
I've been playing with naming my struct method variables "self", we'll
see how this works. I find it easier to read than having it named the
same as the class.