Implement clock_gettime(CLOCK_MONOTONIC) properly

It's bad to pretend to support every clock - we should correctly return -1 with EINVAL for the clocks we don't implement. It's also nice to give implementations a way to detect if they have access to a monotonic clock. For comparison, old Linux machines (RHEL 3 for example) don't have CLOCK_MONOTONIC, new ones do.
Date.now definitely isn't monotonic, it can quite happily jump backwards if the clock time is adjusted, which Windows time update or some unix NTP daemons will do if the clock gets out of sync, if the adjustment is bigger than can be fixed by slewing the clock rate for a while, or users might do themselves.

The name CLOCK_MONOTONIC is also a bit misleading -- CLOCK_MONOTONIC doesn't simply mean "always goes forwards", it really means too that it ticks forwards without any apparent gaps, ie constant rate. If you suspend a laptop, then open it up again, CLOCK_MONOTONIC ought not to jump forwards, and indeed it doesn't on Linux, FreeBSD and AIX systems (clock_gettime not provided on Mac or Solaris). Unfortunately, there are some OS differences here; window['performance']['now'] on Chrome/Firefox on Windows unfortunately does tick during suspend, whereas it doesn't on Unix/Mac, but hopefully the browsers will fix that inconsistency (I have a patch for them!).

The motivation for not providing CLOCK_MONOTONIC is that applications can detect if it's not present and emulate it themselves using whatever jump detection that want from the wall clock time. The C++ libraries we use in our project already do this on Linux: if MONOTONIC is there, it's trusted, and if not, some jump detection heuristics are used to do a best-effort fixup of the wall clock time.