ADDED: timeout and deadline options to thread_send_message

I've created thread_send_message/3 and timeout and deadline options to parallel the same options to
thread_get_message/3. The shared processing has been factored out into process_deadline_options(), so the get and send share exactly the same semantics. The change should not impact on existing code using thread_send_message/2.

I also updated man/summary.doc and man/threads.doc to reflect the changes, but I haven't changed anything in man/Manual/ because (a) it looked a bit scary and (b) I don't know if it's automatically generated.

I would like to clarify one point about the timeout processing as it currently exists: the documentation says that if the timeout is set to zero (0 or 0.0) then the queue is checked but the call does not suspend if the operation cannot be done. I can't see any special handling of this condition in the code: a timeout of zero is exactly the same as a deadline of 'now' as evaluated in process_deadline_options(). Then in dispatch_cond_wait(), 'now' is evaluated again and if the deadline is less than 0.25 s in the future, then pthread_cond_timedwait() is called with the gap between now and the deadline. There is no way to tell if timeout(0) was originally passed as an option. Under no circumstances is pthread_cond_wait() NOT called. Thus, as far as I can see, a timeout of 0 is indistinguishable, either internally or externally, from a very short timeout. This is fine with me. I think it makes sense. But if so, the documentation should probably be changed to say there is nothing special about a timeout of 0. The situation that IS special is when the timeout is negative -- then the message operations fail unconditionally. This is also fine and good, I think. Exactly the same thing happens if the deadline turns out to be in the past.