modularize the command server

From discord:

right now, the command server has 3 jobs: call lifecycle hooks on command handlers (setup, setup_guild, etc) and route events to them (calling handle_event), and track the permissions and event subscriptions for guilds

if we started the framework with a special lifecycle event handler pre-registered, we could just wait for that event handler to do the hard work and tell us when the other handlers are set up

this means we dont have to care about timing or deadlocks when starting/cleaning up handlers, we wouldnt need to prevent setup callbacks from configuring the server, the code for the server gets less convoluted since we only care about event routing

with this kind of special handler, we could go further and have a second one that calculates permissions and subscriptions for us, meaning the server goes from 3 jobs to 1

the only things that would be special about the new handlers are:

• the lifecycle one cant have lifecycle callbacks (duh)
• both must exist for the framework to start since we are hardcoding their subscriptions, so they need to be in the same submodule as the framework

i think we would also be able to drop the special handling of :GUILD_AVAILABLE, :GUILD_UNAVAILABLE, and :GUILD_MEMBER_UPDATE from our consumer code

also, if the subscriptions and permissions are managed by a handler, and we store that info in an ETS table, we could actually merge the framework and consumer modules meaning we could have many server instances since the framework becomes essentially stateless