[expo-modules] Move code from `unimodules` into `expo-modules-core` (#13703)

# Why

Migrated `unimodules-core`, `unimodules-react-native-adapter`, `unimodules-app-loader` into `expo-modules-core`

[expo-modules] Move code from `unimodules` into `expo-modules-core` (#13703)

# Why

Migrated `unimodules-core`, `unimodules-react-native-adapter`, `unimodules-app-loader` into `expo-modules-core`

# How

- Change package using AS refactor tools
- Fix some places where AS wasn't able to do automatically
- Fix compatibility with new auto-linking
- Ensure that classes which are used during installation steps are still available in the old place

# Test Plan

- expo-go (tested using unversioned and 41)
- bare-expo

show more ...

[expo-notifications] Extract Firebase managing responsibility to a composite of the central service (#10558)

# Why

A step towards single-threaded notifications handling

# How

- renamed `Fir

[expo-notifications] Extract Firebase managing responsibility to a composite of the central service (#10558)

# Why

A step towards single-threaded notifications handling

# How

- renamed `FirebaseMessagingService` to `NotificationsService` as it will be now the central dispatch station for all notifications-related actions
- ~introduced a service instance property of new interface `FirebaseMessagingDelegate` which mimics Firebase's `onMessageReceived`, `onDroppedMessages` and `onNewToken` methods, but it introduces a new first argument — a `Context`. We want to be able to access `Context` in methods implementations and also to be able to provide `FirebaseMessagingDelegate` as constructor parameter (as per [discussion](https://swmansion.slack.com/archives/CBGPVEWSV/p1601539802006700?thread_ts=1601495523.018300&cid=CBGPVEWSV)) and since the service is the context and we can't initialize the delegate passing in `this` as an argument before `this` has finished initializing (I didn't think `lateinit` or `lazy` would help here too much)~
- introduced a `lazy` service instance property of new interface `FirebaseMessagingDelegate` which mimics Firebase's `onMessageReceived`, `onDroppedMessages` and `onNewToken` methods
- delegated all the methods to the delegate
- extracted scoped logic in `expoview` in the same manner, noarguments constructor of `ExpoFcmMessagingService`

# Test Plan

I have verified manually that push notifications are still received and that it's the `ExpoFcmMessagingService` which governs it in Expo client.

show more ...

[expo-notifications] add FirebaseTokenListener interface (#8696)

[expo-notifications] Receiving notifications (#6773)

# Why

Another step of `expo-notifications` extraction.

# How

- A singleton `EXNotificationCenterDelegate | NotificationManager` is infor

[expo-notifications] Receiving notifications (#6773)

# Why

Another step of `expo-notifications` extraction.

# How

- A singleton `EXNotificationCenterDelegate | NotificationManager` is informed of new notifications. The information is redirected to `EXNotificationDelegates | NotificationListeners`, which in fact are
- `EXNotificationsEmitters | NotificationsEmitters` which serialize the notifications and emit events to JS.


> Multiple `EventEmitter`s on the image show the situation that will happen in Expo client or when React instance is restarting. In normal situation there is only one emitter per bridge.

> **Note:** what happens to the notification (if it's presented, dismissed, etc) will be decided in another module/PR (handling notifications). Since handling is a non-trivial task (requires communication back and forth) I think splitting those concerns may make the module easier to maintain.

# Test Plan

Received notifications can be printed to `console` when a listener is registered.

show more ...

[expo-notifications] Device push token fetching module (#6577)

# Why

To eventually deprecate ExpoKit.

# How

- created a new unimodule, disabling autolinking in the root projects
- implemen

[expo-notifications] Device push token fetching module (#6577)

# Why

To eventually deprecate ExpoKit.

# How

- created a new unimodule, disabling autolinking in the root projects
- implemented `getDevicePushTokenAsync` method in TS, then in native (on iOS we rely on system framework, on Android we're using Firebase Cloud Messaging)
- implemented listening to token changes

### Notable changes to TS implementation

- I had to juggle around types a bit to achieve what I wanted — for TS to discriminate by `type: keyof Platform.OS` value what is the type of `data` field and at the same time to use `data: any` for unsupported platforms. Types are ready, but I needed to use [`@ts-ignore`](https://github.com/expo/expo/pull/6577/commits/0bd46874ad547f6a1f196adcfc15b6d98614d94f#diff-66b6995155cd1e190f53b012f5c2a857R43-R44) to get away with it.

### Notable changes to native implementation

- we use singleton module for listening to token changes [android](https://github.com/expo/expo/pull/6577/commits/69ee9efd42ba725703fd3f30073564ad3574f1d6#diff-5f9ef5ef7358f7a9c8cc386d42ee934f), [ios](https://github.com/expo/expo/pull/6577/commits/0aa2b66e1342c4de084fc329866752b53b4a6a76#diff-f8332f28b28ad9a24e0af0cb435876c7)
- on Android there's a service subclassing `FirebaseMessagingService` to which the singleton above subscribes [link](https://github.com/expo/expo/pull/6577/commits/69ee9efd42ba725703fd3f30073564ad3574f1d6#diff-b6817886a179022070e2417712503fa9)

### Notable changes to web implementation

- eventually, I guess, developers would want to customize how their app responds to notifications — for this I added a `serviceWorkerPath` manifest field [commit](https://github.com/expo/expo/pull/6577/commits/82e54aeb892b30661e0f5059e64acba70e686f85)

# Test Plan

- tests in `test-suite` are passing on **all three platforms** (on web puppeteer has to be run in head…ful (?) mode, otherwise overriding permissions doesn't work, which is a [known issue](https://github.com/puppeteer/puppeteer/issues/3279))
- push notifications sent to device push tokens are received on **all three platforms**

show more ...