Implement proposed device initialization APIs

APIs to improve time / time zone initialization flow.

Firstly, this change provides a way for SetUp Wizard and similar apps to
ask how confident the device is about time and time zone. This will
remove the need for SUW to watch for changes to the time / time zone
made by the system and infer confidence from that. This SUW "watching"
behavior means that the system cannot set low confidence time / time
zones while SUW is running, as the SUW will interpret them as meaning
the user doesn't need to confirm them.

The remaining methods are to remove the need for SUW and similar apps to
use low-level APIs to force the device's time / time zone into the state
the user wants:

Auto time / time zone detection is usually on by default when SUW runs.
Using low-level APIs to set the time and time zone bypass the system
server time and time zone services' automatic detection behavior. This
leads to either:
(a) the user not getting what they want, i.e. if SUW sets a value, the
detection systems may override them immediately because those auto
detection systems are still active.
(b) the auto detection systems leaving the device set to the values the
user provided incorrectly because they are not aware the low-level APIs
were used.  Typically, the detection systems will kick in at some point
later, leading to an unexpected "random" change if the SUW has forced an
"incorrect" setting.

Instead, what SUW should do is either:
1) Confirm the existing settings.
2) If the user wishes to diverge from the current time or time zone
   settings, there are two cases:
   2a) The device is currently set incorrectly because time / time zone
   detection has not yet determined values yet or has determined them
   incorrectly.
   2b) The user wishes to deliberately set the device to incorrect
   values.

For (1) there are new, dedicated "confirm" APIs. These explicitly handle
if the time / time zone changes while the user is looking at the UI; the
user would presumably be asked to reflect on their choice if they try to
confirm and it now differs from what they are confirming, i.e.  because
it has become case (2).

For (2), the current value is considered wrong by a user. New "get
state" APIs can be used by SUW to understand device confidence. For (2b)
the user is overriding a "confident" value and so SUW may want to inform
the user / ask if they are sure and and leave auto detection turned off
after setting the incorrect value. For a user to set a new value, the
high level APIs only allows this if auto detection is off. Auto
detection state can be determined by APIs exposed here. Auto detection
can be turned off via the APIs too and "manual" values can be set via
other APIs. Auto detection can then be turned back on (if required).[*]

[*] At any point after auto detection goes back on the device can choose
a different time / time zone from the one the user chose. The SUW could
wait for a short period to "settle" and re-check or just ignore this
possibility and proceed to the next step immediately.

Test: atest services/tests/servicestests/src/com/android/server/timedetector
Test: atest services/tests/servicestests/src/com/android/server/timezonedetector
Test: atest core/tests/coretests/src/android/app/time
Bug: 236612872
Change-Id: I1903569907e7e268155814193379b7eef2e75a8d