Refined iOS lifecycle handling.

iOS has two different things going on, which we were previously not mapping
properly onto the PlayN lifecycle. An iOS app can "resign activation" and then
"resume activation", which it does when interrupted by a phone call, or as it
turns out, when the user goes to make an IAP. In this case, the app needs to
slow down to let the user decide whether or not to take the call, but the app
is not yet being backgrounded, and may not if the user decides not to take the
call. So we just pause the renderer in those cases (per iOS recommendations)
but leave the app "running" as it were.

If the user takes the call, or if they switch to another app, then the app is
"backgrounded" which is the moral equivalent of PlayN's "paused". So then we
tell the app that it's being paused, and when it is "foregrounded" we tell it
it is being resumed.

This means that an app will no longer get an onResume call immediately after
starting up, but I think that's more sensible as I'm pretty sure none of the
other platforms do that either.