Adds state_machine to manage ticket state transitions.

Originally, Ticket state was managed through an association with a
State instance. The idea was to allow for installations of the system
to create their own workflows. However, after adding ticket searching
capabilities, I think having a predetermined finite set of states makes
more sense. This allows for the creation of some default ticket search
filters as well (pending at this point). Given the transition to a system
of finite states and determinate transitions, refactoring to a state_machine
implementation was natural...and hence this commmit.

The introduction of the state_machine simplified some things, making the
2 TicketConductors I have in the system a bit superfluous at this point.
They don't have as much work to do now that ticket state isn't managed via
an associated model, so they are on the chopping block in the next commit.

Introducing the state_machine also highlighted some limitations of specifying
authorization rules via the current implementation. There are a few warts
in the TicketController right now, but those will be dealt with in a
planned move to Pundit for managing authorization (it makes fine grained auth
controls easy on individual paramaters, which is what is needed at the
moment vis-a-vis the state_event param on the tickets hash).