Revert "hwclock-rtc.c: try the 'new' rtc class first"

Revert "hwclock-rtc.c: try the 'new' rtc class first"

This (effectively) reverts commit
1811900a91be856e794005511eac7859adb8e383.

There was no real motivation given, and it certainly makes the default
behaviour of hwclock on current linux systems counter-intuitive: udev
has a standard rule so that whichever rtc device is designated as the
CONFIG_RTC_HCTOSYS_DEVICE one in the kernel configuration also becomes
the target of the /dev/rtc symlink. People may have some other way of
setting that symlink, but regardless, that must be considered the
primary or default rtc for the system.

Also, busybox's implementation of hwclock still uses the original
/dev/rtc, /dev/rtc0 order, meaning that installing util-linux's
version on a board previously using busybox leads to unexpected
regressions - it's not at all clear that one must go around and stick
--rtc /dev/rtc on every hwclock invocation in all scripts.

While it's usually busybox that should align with the full-fledged
implementation, in this case, I do believe that util-linux is
wrong.

There is no change in behaviour on systems that for some reason do not
have a /dev/rtc symlink, or for which it is a symlink to rtc0 (such as
on any board with only a single RTC device). However, I do understand
that reverting this after 8 years can itself lead to regressions, and
I can understand if it would be rejected for that reason. However, in
that case I'd appreciate a config option so that one can choose the
primary rtc device at build time.