Automatically re-join calls after code-push-triggered reload

[ebroder]

If Meteor triggers a page reload due to out-of-date code, stash the current state of whatever call we're in in sessionStorage, and use that to automatically re-join the call afterwards. We do some shenanigans to ensure that this only happens when Meteor triggers a page reload (as opposed to the user refreshing the page on their own).

Fixes #1314

This doesn't 100% work yet - it doesn't suppress allowInitialPeerStateNotification, so if you're muted and the page refreshes for a code push, you'll get the large call popup. It's also somewhat annoying to test in development mode, because hot-module-replacement completely prevents Meteor-drive page reloads. I temporarily ran meteor remove hot-module-replacement temporarily in my local copy for testing, although I think that completely stopping and restarting the Meteor server might also trigger a full-page refresh.

[zarvox]

One thing that I'm not totally sure about is if the goal of this is actually reliably achievable under certain browser-enforced policies about media capture and playback, particularly being able to obtain an AudioContext or microphone capture before any user interaction takes place in the document. In the case where the user has granted persistent microphone capture to the origin, I think we're probably fine. However, if the user granted a one-time permission grant (which I'll point out is Safari's default behavior, and that you have to poke around in the UI to find a way to grant permission persistently), I could totally believe that the user would get prompted or if there was no mouse or keyboard event on the page, that the getUserMedia request might be dropped entirely.

[zarvox]

I suppose in those cases it's still probably a win for them to get re-prompted rather than just silently dropped from the call, but we might have to either temper our expectations or otherwise guide users toward enabling persistent audio access.

[ebroder]

Closed in favor of #1329