Introducing an interface to store alarms

The alarms inside alarm manager service are stored in a variety of
different lists, the main one being an array list of Batch objects. Over
time due to various policy changes, it has caused a lot of coupling
between the service's business logic and the management of these data
structures.

This change introduces an interface to store alarms (a.k.a. AlarmStore)
and attempts to create a well defined boundary across which the service
interacts with this data structure. The interface presently supports
the following operations:
- add: to add an alarm.
- remove: to remove any alarms described by a predicate.
- removePendingAlarms: to remove any alarms that are due at a given
time.
- getNextDeliveryTime: the next upcoming alarm's delivery time.
- getNextWakeupDeliveryTime: the next upcoming wakeup alarm's delivery
time.
- recalculateAlarmDeliveries: to adjust the alarm deliveries in a way
described by the caller.
All the times are interpreted in the elapsed timebase.

The details of how the alarms are stored and managed, such as their
relative ordering and the complexity of each of the supported operations
is left to the implementations to decide. The expectation is that
this will make it easier to change and optimize these aspects of the
data structure in the future, while also making it simpler to make
changes to the service side policies.

Apart from the above, some formatting was corrected, obsolete or dead
code was removed and a bug where we were missing a rebatch was fixed.

Test: atest FrameworksMockingServicesTests:com.android.server.alarm
atest CtsAlarmManagerTestCases

Bug: 161497385
Change-Id: I8ac475d6c6a827500bf93be982cd40897f6743ae