Resolve "signalc: handle incoming signal messages"

Closes #412 (closed)

context

• In !496 (merged) and !500 (merged) we added the ability for signalc to register a number and send messages from it across multiple sessions in our demo cli app
• This MR adds the ability to receive messages, ensures that we receive messages in a concurrency-friendly manner (using coroutines and channels), and circles back to make previous code similarly concurrency-friendly

changes

logic layer

Add SignalMessageReceiver

• #receiveMessages reads messages off pipe from signal inside a coroutine, then puts them on a channel for the caller to consume
• we leave lots of corner cases unimplemented for now in the interest of driving toward validating with load tests but have tickets waiting for, e.g.: handling broken connections (#421 (closed)), dealing with duplicate supscription attempts (#425 (closed)) and unsubscribing from subscribed accounts (#424 (closed))

Add SignalMessageDispatcher

• #subscribe uses SignalMessageReceiver to receive messages for an account and returns a channel that callers may read processed messags off of
• for now, "processing" means decrypting cyphertext messages, reporting decryption errors, and reporting messages it does not know how to handle
• we eventually want to handle more kinds of messages and handle decryption errors more granularly, but leave that for later cards in the interest of driving to load testing. for corner cases, see, e.g., #400 (closed), #402 (closed), #403 (closed)

config / application layer

• suspend all the things!

  • Several changes follow from introducing coroutines and channels to read messages from Signal (the "suspending" nature of these functions essentially bleeds out into the rest of the code base). specifically...
  • add CoroutineContext as param to Application constructor (and modify tests to provide a testing coroutine context via runBlockingTest)
  • make all AccountStore methods (and their callers in AccountManager) suspending
  • we can't make ProtocolStore methods suspending (b/c they override blocking methods inherited from Signal superclasses), but we set our minds at ease about this by making all functions that every call protocol store methods suspending (eg: SignalMessageReceiver#receiveMessages, SignalMessageSender#send, etc..)

• and some random cleanup..

  • add certificateValidator and clientZkOperations fields on Application.Signal (needed for decryption ops in SignalMessageDispatcher)
  • alphabetize fields on Config.Signal (there's getting to be a lot!)
  • rename MessageSender -> SignalMessageSender for consistency

demo update

• Main uses SignalMessageDispatcher#subscribe to read messages for an account and print them to stdout as they come in! (so you can now both send and receive messages!)