Fix clearing notifications when the application becomes active instead of when it enters foreground

[emawby]

Description

One Line Summary

Fixes a bug where opening the notification center while in the app would clear notifications

Details

The application active state is different than the application foreground state. The app resigns and becomes active if the app is interrupted by the notification center even though it remains in the foreground. We previously were dismissing notifications in didBecomeActive so when the notification center was opened while the app was foregrounded we would dismiss notifications.

There also seems to be an apple bug where the resign and become active triggers would fire twice as you are swiping down the notification center. This means that we were dismissing the notifications as you open the notification center which made the problem even worse.

I refactored where we handle notifications related tasks in response to application lifecycle events. The OSNotificationsManager now registers itself to listen to the lifecycle and handles changes on the foreground event.
I also moved checking if the app is using UIScenes to OneSignalCore.

Motivation

bug fix

Scope

notifications and application lifecycle

Testing

Unit testing

Created a new unit testing target for OneSignalNotifications and added it to the UnitTestApp target.

• Added 3 simple tests related to listening to foregrounding the app

Manual testing

• Tested backgrounding and foregrounding with and without notifications with badges
• Tested changing the permission value in the background and then foregrounding
• Tested resigning and regaining active using the notification center while the the app was foregrounded

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[nan-li]

nit, this comment should say "count == 1"?

[nan-li]

The new files created can clean up the headers?