Blogging Prompts: Add wrapper component to interface between schedulers

[dvdchr]

Refs #18761

This PR adds ReminderScheduleCoordinator as a wrapper component that can decide whether to use BloggingRemindersScheduler or PromptRemindersScheduler.

The component will decide to use the Blogging Prompts scheduler when all of these are true:

• The feature flag for Blogging Prompts is enabled,
• If there exists a settings object for Blogging Prompts in local storage (BloggingPromptsSettings),
• and the promptRemindersEnabled property is true. This property tracks and gets updated whenever the Include Prompts switch is toggled in the reminder sheet.

In other cases, the coordinator will fall back on the Blogging Reminders scheduler.

To Test

Ensure that the unit tests are passing.

Regression Notes

1. Potential unintended areas of impact
   N/A. Feature is unreleased and component is not yet used.

2. What I did to test those areas of impact (or what existing automated tests I relied on)
   N/A. Feature is unreleased and component is not yet used.

3. What automated tests I added (or what prevented me from doing so)
   Added unit tests.

PR submission checklist:

• I have completed the Regression Notes.
• I have considered adding unit tests for my changes.
• I have considered adding accessibility improvements for my changes.
• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[wpmobilebot]

You can test the changes in Jetpack from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr18772-bf4c0c8 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

[wpmobilebot]

You can test the changes in WordPress from this Pull Request by:

• Clicking here or scanning the QR code below to access App Center
• Then installing the build number pr18772-bf4c0c8 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

[wargcm]

The tests pass and the code looks good to me!

[dvdchr]

The unit test failure is pretty weird. After spending a bit digging into this, it looks like there are other "live objects" subscribing to the account change notification after calling setDefaultWordPressComAccount.

The core problem, as I understand, is that different objects hold different context managers but they share the same user defaults; which can lead to inconsistency that caused some stored values to be wiped. In this case, [AccountService defaultWordPressComAccount] will delete the account UUID stored in user defaults if the WPAccount matching the UUID doesn't exist. (Well, it exists on the context manager in my test suite, but it definitely does not in other contexts 😅 )

I think UserDefaults needs to be mocked somehow in unit testing, so we can control what goes in and out.

(cc: @mokagio & team)

[mokagio]

Thanks for the ping @dvdchr! I opened #18778 to track the need for a deeper UserDefaults-usage cleanup.