Figure out what exceptions should be thrown by the ipmSender and ipmReceiver classes

[jcfreeman2]

One of the arguments given for the existence of the ipm interface classes is that they can throw the ERS-type exceptions chosen as a standard for DUNE DAQ software back in the summer. To this effect, we should carefully think about which exceptions should be thrown by the ipmSender and ipmReceiver classes. For the purposes of argument, let's think about what happens then ipmSender::send is called. While we could just let exceptions thrown by implementors of the (virtual protected) ipmSender::send_ function sail out of its (nonvirtual public) wrapper function ipmSender::send without any vetting inside of ipmSender::send, that would of course expose developers polymorphically using the ipmSender and ipmReceiver classes to implementation details. By vetting, here I mean something along the lines of ipmSender::send posting a message to the effect of, "The implementor just threw an unknown exception, but here's all the info from it which I can extract", and then calling std::terminate if an exception left ipmSender::send_ which it didn't recognize.

A couple of things to think about:

• Given that 0MQ's probably going to be the main implementation library for a while, how crazy is it to suggest we just translate the cppzmq exceptions (which in turn wrap the error code/error string provided by 0MQ's zmq_errno and zmq_strerror) functions into ERS exceptions?
• An argument against that is that the set of errors provided by 0MQ is too fine-grained or (less likely) not fine-grained enough for our purposes. Another argument against it is error codes which make sense in a 0MQ-specific context but not in a generic ipmSender/ipmReceiver context.
• The absolute most basic baseline - the opposite of the "let's map all the 0MQ errors" suggestion - would be to have a generic exception along the lines of "There was some problem with the ipmSender::send_ call inside of ipmSender::send

[eflumerf]

Some of this is implemented in #32