libc: picolibc + common: time() should not refer to POSIX functions

[cfriedt]

Notes
C libraries should be usable without any implicit assumption about the presence of a POSIX API. That's historically not been the case for newlib, and as a result, some of that has spilled over into picolibc.

One such instance is the ISO / ANSI C89 call time_t time(time_t *arg) function, which returns the calendar time encoded as a time_t object, or (time_t)(-1) on error.

https://en.cppreference.com/w/c/chrono/time

Currently, the picolibc time() function calls gettimeofday() which is a POSIX API call. The problem is, we don't want to have POSIX if we can exclude it.

The common libc time() falls into a similar problem because it relies on the POSIX clock_gettime() call.

Describe the bug
See above

To Reproduce

1. remove CONFIG_POSIX_TIMERS=y from tests/lib/time/prj.conf
2. build
3. See error (undefined reference to gettimeofday()

Expected behavior
What I would expect is that there is a Zephyr-native function that can report the time since the epoch in a reusable way, and that both the common ISO / ANSI C89 time() and the POSIX gettimeofday() both reference that common implementation.

A possible option would be to move the majority of lib/posix/options/clock.c into the domain of the Zephyr kernel, prefix calls with a k_ and call it a day. Some constants would need to be declared for K_CLOCK_REALTIME, K_CLOCK_MONOTONIC, etc.

They also don't necessarily need to be part of the kernel, and could just be made into a separate library. The main way that time is tracked here is via k_uptime_ticks() anyway.

The POSIX API would simply wrap the Zephyr kernel API (or library API).

The common libc time() call (and others?) would then be free to call the common API instead of the POSIX API, and there would be no dependency cycle.

Picolibc would elect to use the common libc time function call instead of providing its own. Likely newlib would do the same.

Impact
It's an annoyance. Kind of a showstopper as I was trying to get #88547 done today, and ran into this issue as well as another, more POSIX-specific one.

Logs and console output

Environment (please complete the following information):

• OS: (e.g. Linux, MacOS, Windows): any
• Toolchain (e.g Zephyr SDK, ...): Zephyr SDK v0.17.0
• Commit SHA or Version used: 781011b

Additional context

See also #88556