Use CLOCK_MONOTONIC rather than CLOCK_REALTIME

Use CLOCK_MONOTONIC rather than CLOCK_REALTIME

This changes the clock used internally by ORTE for timestamps in the
protocol and for timing of internal operations. Previously,
CLOCK_REALTIME was used, probably because it is the default clock used
by pthread_cond_timedwait(). Using CLOCK_REALTIME has the disadvantage
that the time can "jump", e.g. when the clock is adjusted by ntpdate.
This causes the applications to stop publishing, which results in them
disappearing from the domain even through their processes still run.

The solution implemented in this commit is to switch the clock to
CLOCK_MONOTONIC, which does not jump. This should have no effect at the
protocol level, because the semantic of timestamps is not defined in the
spec. This was also tested by running the implementations with and
without this change against each other.

In future, it might be a good idea to use different clocks for
timestamps in the protocol and for timing of internal operations (e.g.
ORTEAppSendThread()). I'm not sure what happens in the following two
cases:

1) When one node is suspended to RAM/disk, CLOCK_MONOTONIC stops for the
   time of suspension and it is not clear to me what other nodes that
   run continuously do when the suspended node resumes.

2) When a node is rebooted, the monotonic clock starts from zero, i.e.
   there is a "jump". I'm not sure, whether IDs of the application
   before and after reboot will be different. UDP ports, that are a part
   of the ID should be randomized, but the question is how good this
   randomization is. If the ID is the same before and after reboot some
   problems might also appear.