producer-consumer flow for irc messages receiving and processing

[triacontakai]

problem:
current design has no way to wait for a message
since there is no way to predict the order of processing, it is not possible for a user to implement a system where they wait for another event in a message (since the event they want could have already been processed)

solution:
this potential "conversation" style behavior can be made possible by queueing messages into an asyncio.Queue, which will allow _recv_loop to continue working asynchronously of a single message processing task, but allow the latter to process messages sequentially

things to consider:

• an on_message taking a long time will block processing sequential messages
  • this isn't something that can be solved with this system, since this is a direct side effect of serial processing
  • will not initially block receiving loop (because of queue), but can potentially block if it takes a long time and queue fills up
    • irc I/O should ideally be the bottleneck
• should a message/event that is being waited on trigger the handler for itself as well?
  • probably not, since if a client is waiting on an event they likely don't want to trigger the handler for it
    • if they want to anyways, then can just manually call the handler themelves
• provide another queue for irc messages -> game events, allowing for waiting on specific game events and not having to process them
  • will require restructuring of how messages are handled, since on_message is used by GameClient and can't be overridden by a subclass
  • maybe separate producer/consumer logic into different classes?