fix: removes listeners when app is reloaded on android

[fadi-george]

Description

One Line Summary

• addresses this comment ([Bug]: Problem with addEventListener removeEventListener #1610 (comment)) where when app is reloaded, the old listeners arent properly removed

Bug:
https://drive.google.com/file/d/1TOP4Wcm92Z7HsW-ElALr_tqsQYO6IGYU/view?usp=drive_link

Fix:
https://drive.google.com/file/d/1mz56DI5mfIN0tnfME0QQmiVpQt6hXUeO/view?usp=drive_link

Details

• adds RN static instance to RNOneSignal java class so we can clean up its old handlers when a new instance is created

Motivation

• When doing a reload on the terminal or devtools window, previously any added listeners would just linger so for each reload you would seen an extra log.

Manual testing

Update OSDemo to have:

  const handleForegroundNotification = useCallback(
    (event: NotificationWillDisplayEvent) => {
      const notification = event.getNotification();
      console.log('Arrived', notification);
    },
    [],
  );

  useEffect(() => {
    const setup = async () => {
      OneSignal.Debug.setLogLevel(LogLevel.Verbose);
      OneSignal.initialize(APP_ID);
      OneSignal.Notifications.addEventListener(
        'foregroundWillDisplay',
        handleForegroundNotification,
      );
    };
    setup();

    return () => {
      OneSignal.Notifications.removeEventListener(
        'foregroundWillDisplay',
        handleForegroundNotification,
      );
    };
  }, [handleForegroundNotification]);

Run bun run android in the example project.
Send a test notification to some test subscription.
Click on the react-native terminal.
Should see 1 log per notification.

Compare against the video in the description where you see multiple logs per sent notification.

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