CLOCK_MONOTONIC change reverted

To be honest, what confused me most here was the approach taken to making the change. If a behavior is as useful and widely-documented as CLOCK_BOOTTIME vs. CLOCK_MONOTONIC is (and believe me, the _behavior_ distinction is very useful regardless of name), why was doing a straight renaming in one shot _ever_ considered?

When a behavior's name is suboptimal, there's a pretty well established way of fixing that - introduce a new name, deprecate the old name, and have a deprecation cycle.

1. Add CLOCK_MONOTONIC_ACTIVE as an alias for CLOCK_MONOTONIC, deprecating CLOCK_MONOTONIC (maybe add #warning)
2. Add an #ifdef that people can set to switch (deprecated) CLOCK_MONOTONIC = CLOCK_MONOTONIC_ACTIVE to (new) CLOCK_MONOTONIC = CLOCK_BOOTTIME
3. Flip the default ifdef, after waiting long enough
4. Deprecate CLOCK_BOOTTIME (maybe add #warning)
5. Remove CLOCK_BOOTTIME, after waiting long enough
6. Remove the #ifdef, after waiting long enough (this is last because previous stages _introduce_ errors or at least warnings, while this would cause build-silent misbehavior, as was seen with the current patch)

I cannot think of a reason that "just change it" was considered viable for public, documented API and ABI?