Fix logic used for auto time zone settings

Fix the logic used that determines whether the automatic time
zone detection toggle is available in the Settings UI Date & Time
screen. Also, ensure that the TimeZonePreferenceController uses correct
logic for whether the user can manually enter a time zone.

This change migrates the controllers to use a existing high-level
TimeManager API rather than (incorrectly) duplicating in Settings UI the
logic for whether time zone detection is supported / enabled.

Without this change, WiFi-only devices _with_ location-based time zone
detection enabled would incorrectly hide the "auto time zone" toggle,
which would have the knock-on of making it look like the user is allowed
to enter a time zone manually when they aren't (because it is
enabled/disabled based on the presence of the toggle).

That toggle still needs to be present while there is a possible time
zone detection mechanism. All the (quite complex) logic around this is
already considered by the TimeManager API.

Possible side effects:

This change decouples the "does the toggle show true or false?"
(isEnabled()) from the "should the toggle be shown at all?"
(isAvailable()) logic by removing a call to isAvailable() inside of
isEnabled(). This is to avoid making multiple (probably more expensive
than what it was doing before) calls to the time_zone_detector service,
and avoid the extra complexity of caching / cache invalidation that
would be needed to mitigate it. Previously, as a result of the call to
isAvailable(), isEnabled() would always return false when mIsFromSUW is
true, but now it will return the underlying value of the device's
auto_time_zone setting. This means that if the UI is changed in future
to render a visible-but-can't-be-changed-by-the-user toggle for auto
time zone, it will display the current setting value, which is perfectly
reasonable.  It is assumed it will have no other side effects.

The AutoTimeZonePreferenceControllerTest.isFromSUW_notEnable test has
been changed to reflect the change in behavior. Various name changes
made to tests to reflect the new behavior.

Bug: 228247623
Bug: 186625820
Bug: 172891783
Test: treehugger
Test: Manual test on a device with telephony
Test: m ROBOTEST_FILTER=AutoTimeZonePreferenceControllerTest RunSettingsRoboTests -j40
Test: m ROBOTEST_FILTER=TimeZonePreferenceControllerTest RunSettingsRoboTests -j40
Change-Id: I4c7608e8645eee5994c8ecf85a14a27d3278ac04

src/com/android/settings/datetime/DateTimeSettings.java

@@ -85,8 +85,7 @@ public class DateTimeSettings extends DashboardFragment implements
 
         controllers.add(new TimeFormatPreferenceController(
                 activity, this /* UpdateTimeAndDateCallback */, isFromSUW));
-        controllers.add(new TimeZonePreferenceController(
-                activity, autoTimeZonePreferenceController));
+        controllers.add(new TimeZonePreferenceController(activity));
         controllers.add(new TimePreferenceController(
                 activity, this /* UpdateTimeAndDateCallback */, autoTimePreferenceController));
         controllers.add(new DatePreferenceController(