Potential issues by using non-monotonic clocks

[ghost]

There are a few invocations of non-monotonic clocks that may require closer examination. These include:

• org.freedesktop.dbus.utils.TimeMeasure -- I think this class isn't used and can probably be deleted to prevent its use in the future.
• org.freedesktop.dbus.connections.SASL -- Issue SpotBugs analysis: SASL.findCookie and SASL.addCookie may fail to close streams #205 notes a few occurrences of possible non-monotonic clock issues. There may be more, including:

            Message.marshallintBig(System.currentTimeMillis(), buf, 0, 8);
// ...
            long start = System.currentTimeMillis();
// ...
            while (lCookie == null && (System.currentTimeMillis() - start) < LOCK_TIMEOUT) {

This one would depend on how the marshalled ID is used:

                    long id = System.currentTimeMillis();
                    byte[] buf = new byte[8];
                    Message.marshallintBig(id, buf, 0, 8);

• EmbeddedDBusDaemon::startInBackgroundAndWait, RunDaemon::startDaemon, and RunTwoPartDaemon::startDaemon have effectively duplicate code blocks for busy-waits. I think startInBackgroundAndWait can be removed. If not, consider refactoring the duplication to make finding and reviewing the code for potential timing-related issues easier.
• The unit tests AbstractBaseTest and AbstractDBusBaseTest also duplicate the same code. These could be refactored to simplify the code base and make finding potential timing-related issues easier.

I couldn't find anything else of note with respect to non-monotonic time.

[hypfvieh]

I removed the usage of System.currentMillis().
In case where some sort of "wait for lock" was used, I now use TimeMeasure. It was originally intended for debugging only (measuring runtimes). I updated the code of TimeMeasure to use System.nanoTime() and added the required function for the measuring the locking stuff.

Regarding the duplicated code: No EmbeddedDBusDaemon::startInBackgroundAndWait cannot be removed. It is public API.
I moved the wait stuff to a more generic method in Util. Now the Util.waitFor method is called when waiting for something is required.