Adding uid attribution mechanism for kernel wakeups

BatteryStats currently only stores the reason it receives from the
suspend control service. Starting with this change, batterystats will
now try to attribute these wakeups in more detail.

IRQ style wakeups where there has been an IRQ from a device get a
well structured reason string from the kernel. CpuWakeupStats will parse
it to get irq devices and then use irq_device_map xml to map the wakeup
to possible pre-defined subsystems that may have caused it.

Different parts of the system can use these subsystems to report any
associated activity (not to be confused with the class
android.app.Activity) tha could have caused a wakeup. CpuWakeupStats
will then attempt to associate this information with any wakeup that
may have occurred due to an IRQ from the relevant device.

This change defines the "Alarm" subsystem, and relies on the device
overlay to map this subsystem to the rtc device that ultimately enables
waking up the CPU when needed to process a wakeup alarm. Whenever there
is a batch of wakeup alarms that is dispatched, alarm manager notifies
batterystats (and hence cpuwakeupstats) of this "activity", which will
then try to associate it with any temporally proximal wakeups that have
happened due to the rtc device.

Currently, the information supported is only the uids that have
requested or initiated the activity from the subsystem that should be
blamed for the wakeup. But this can be extended to include more enum
style codes to represent other information.

Test: atest FrameworksServicesTests:IrqDeviceMapTest
Test: atest FrameworksServicesTests:CpuWakeupStatsTest

Bug: 249370357
Bug: 195684213
Change-Id: Idfbba82e9c007b5c9f15b9fd785b9a96cb202572