Make more transparent how ZCM works internally

[ernestum]

Like most APIs, ZCM provides a leaky abstraction. E.g. we are not allowed to subscribe/unsubscribe inside of handlers and it a handler blocks, no other handlers get executed. Why this is the case becomes far more clear when we look at the following diagram, which we could include in the documentation:

This could also be the place where we explain, that the difference between zcm_run and zcm_start is only whether the handle thread gets executed in a new thread or in the current thread (one might be tempted to think that the zcm_run variant does not start any new threads).

[jbendes]

I'm actually more a fan of making it not a "leaky abstraction" but documentation definitely never hurts. Do you have a thought as to where in the documentation flow this type of explanation would go? A reminder that this is only for the blocking transport api. zcm at the api layer does not do this stuff (hence the leaky abstraction)