Draft: main/busybox: revert special hwclock handling for musl

From #alpine-devel:

16:19:12 (dalias) alpine should add this patch for busybox: http://sprunge.us/Kd7xLC
16:19:33 (dalias) it fixes a regression that silently starts corrupting users' timestamps on fatfs filesystems
16:20:17 (dalias) see https://www.openwall.com/lists/musl/2024/03/03/3
16:25:05 (ikke) nmeum: ^
16:28:07 (nmeum) has this been reported to busybox upstream?
16:31:16 (dalias) they were cc'd on the email
16:31:37 (nmeum) *nod*
16:32:03 (dalias) both toybox and busybox seem to have a weird policy on this type  of thing "we want to actively reject the choices of the OS and try to undermine it to behave like GNU/Linux instead"
17:12:45 (nmeum) why does using the "kernel-timezone functionality" break fatfs timestamps? also I don't get why busybox upstream decided to add special handling for musl to hwclock in the first place, would prefer if this would be sorted out upstream

See: https://www.openwall.com/lists/musl/2024/03/03/3

Presently, it is not entirely clear to me why this is needed. Specifically the following things should be sorted out:

1. Why did upstream BusyBox add special handling for musl to hwclock in the first place?
2. What specific issues does this special handling cause? Is it just compilation issues on riscv32 or are there any other side effects ("corrupting users' timestamps on fatfs filesystems")?
3. Can we get upstream BusyBox to sort this out for us?