Handle exact alarm permission state changes

The permission SCHEDULE_EXACT_ALARM state changes at the following
boundaries:
 1. App-op: This gets toggled by the user via Settings.
 2. Deny-list: Packages can be added to the deny list via DeviceConfig
 APIs.
 3. Package changes: A package's manifest may changes when it gets
 updated.

In both cases 1 and 2, if alarm manager detects a permission change
from revoked to granted, it sends the
ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED broadcast to the
app.
If it detects a permission change from granted to revoked, it kills
all the processes within the hosting uid.
In all three cases, when the permssion changes from granted to revoked,
all the exact alarms scheduled by the relevant package are removed.
Package updates are treated differently as they require processes to
restart anyway. The broadcast is not needed in this case as there
are no alarms expected to have been lost by a previous revocation, and
apps can always use ACTION_MY_PACKAGE_REPLACED for post-update setup as
usual.

All this only applies to packages that have the change
REQUIRE_EXACT_ALARM_PERMISSION enabled.

Also changed canScheduleExactAlarms to return false if the change is not
enabled for the calling package.

Test: atest FrameworksMockingServicesTests:AlarmManagerServiceTest
atest CtsAlarmManagerTestCases

Bug: 179541791
Bug: 187206399
Change-Id: Icd68275701f2804be65b3a10a7dd81bbf6e2a0bb