Build: restore buildability in the face of obsolete ftime(3)

Since the usage of ftime(3) is purely optional and since
clock_gettime(3) is mandated with POSIX 2001, we can simply
look at whether CLOCK_MONOTONIC is defined to be used as an
identifier for the particular clock (kind exactly suitable
for this context). But due to being late in the release cycle,
such a change is kept as opt-in (see configure.ac comment for
details), and for compatibility stability concerns[*], also
dropping some old surrounding cruft is delayed.

In this form, constitutes first step out of two to restore
out-of-the-box buildability with recent enough glibc, again,
refer to configure.ac comment.

References:
https://sourceware.org/git/?p=glibc.git;a=commit;h=2b5fea833bcd0f651579afd16ed7842770ecbae1
https://src.fedoraproject.org/rpms/glibc/c/ebf75398f06dd27357d8a5321e8e5959633b8182?branch=master
(for a Fedora Rawhide follow-the-upstream update that led to this
discovery)

• in case you opt-in (as described), CLOCK_MONOTONIC gets detected in time.h positively but it starts choking for whatever reason in the actual build or even in run-time, you can rescind that, or you can shortcut any checking and refrain from any time period measurements altogher with something like:
  
  env \ ac_cv_header_sys_timeb_h=no ac_cv_have_decl_CLOCK_MONOTONIC=no \ ./configure