Cross-platform consistency for `ApplicationHandler::suspended/resumed()`

Unfortunately the behavior between Android, iOS and Web doesn't match exactly, so this will require some research and figuring out exactly how we want to expose this to the user.

Web

Web currently implements this via pagehide and pageshow. Which for suspended() means the application is being navigated away from and is being stored in the B/F Cache and for resumed() means that the page has been restored.

Its important to note that between suspended() and restored() no user code can be executed and getting restored() isn't actually promised.

There is also the Page Lifecycle API, currently only implemented in Chrome, which lets us also detect if the application was frozen by the browser.

iOS

@madsmtm please feel free to work out this section and correct me.

applicationDidEnterBackground could be used to detect when iOS is telling the application to stop doing anything. This doesn't mean that any code execution will be suspended immediately but "probably soon".

This however is currently not implemented correctly and instead iOS will call ApplicationHandler::suspended() when the application is running in the background via applicationWillResignActive, which should probably be WindowEvent::Focused(false) instead.

Presumably its also guaranteed that the application will be woken up before being actually closed (?).

Android

@MarijnS95 your input would be greatly appreciated here.

Android does currently not implement ApplicationHandler::suspended/resumed()

Start with the ApplicationHandler::suspended/resumed() entry points and compare the Web pagehide/pageshow behavior with the iOS applicationDidEnterBackground and applicationWillResignActive hooks. Research the Android lifecycle behavior and determine how these platform events should map to the user-facing API. Done means the cross-platform semantics and implementation scope are agreed, including the distinction from WindowEvent::Focused(false).