[expo-notifications] Scheduling notifications (#7035)

# Why

Next feature!

# How

On iOS implementing this feature was fairly simple, all we needed was to expose methods triggering `add/get/r

[expo-notifications] Scheduling notifications (#7035)

# Why

Next feature!

# How

On iOS implementing this feature was fairly simple, all we needed was to expose methods triggering `add/get/removeNotificationRequests`, `UserNotificationCenter` took care of everything else for us.

On Android however, we needed to implement `UserNotificationCenter` ourselves. The scheduling part of it is located in the new `ExpoNotificationScheduler` job intent service, which handles three types of intents:
- `schedule` — extras should contain the notification request, enqueued by any scheduling module — the request is stored in persistent storage and an alarm triggering the notification is scheduled on `AlarmManager`
- `remove` — extras should contain the ID of the request to cancel and remove — the request is removed from the storage and alarms are cancelled
- `trigger` — extras should contain the ID of the request that is triggered — notification is fetched from the store, handed over to `NotificationsService` and rescheduled
- `boot completed` — all known notifications are rescheduled (**note:** we could think about supporting [_Direct Boot mode_](https://developer.android.com/training/articles/direct-boot) if `SoLoader` would support it too. Unfortunately it does not, so there's not hard reason for us to do it.)

The architecture looks more or less like this (elements relevant to this PR are left opaque)


An interesting part are triggers, which let us create a simple way to schedule notifications. At the moment there are 2 schedulable notification triggers: `DateNotificationTrigger` and `TimeIntervalTrigger`. The former one will trigger at one specific date and it will never repeat, the second one will trigger at time intervals from the date of creation (optionally repeating).

This PR will also allow us to remove the NotificationPresenter module, since (as it is on iOS we can handle this case likewise on Android) presenting is scheduling with `null` trigger.

It may look like this PR adds a little bit more of complexity to types with which the native side can communicate with JS, but that is not the case — we reuse the serializers already present on `master`. The one thing left, which I intend to do after all the major PRs land is to refactor the TS side (colocate relevant types, make the folder structure more hierarchical).

# Test Plan

Added a test suite covering this API, passing on iOS 13, Android 7 and 9 devices.

show more ...