Bug 915643 - [Email] Clear old notifications once Notification.get is available

This changeset contains the fix for bug 915643 and also some groundwork that will be reused later for bug 922722, but is also used to fix bug 915643.

For bug 915643, closing notifications for an account if inbox is shown: the general goal is to close the notification if the inbox is shown. The user will have seen the new messages, so the notification is no longer needed. The changes:

1) It is important to only close the notification if the inbox is visible to the user, and not if the email app is in the background. The Cards object now listens for visibilitychange events and if the current card implements a onCurrentCardDocumentVisibilityChange method, it will call this method. compose was converted to use this instead of registering its own listener. It is used by message_list to determine if an 'inboxShown' evt should be emitted.

Both compose and message_list were tested to confirm the mechanism works, and that compose correctly saves drafts as before.

2) sync.js listens for 'inboxShown', and if there is a notification for that account, it removes it. Recall that there is only ever one notification per account that is in play at any given time.

For bug 922722, updating message count across multiple syncs:

The part about actually retrieving the old notification has been commented out because of bug 1033933, just discovered, messes with the counts. However, I left the bulk of the code for bug 922722 in, since a lot of it is reused for bug 915643, and it was going to be more work to separate them, and create a bigger diff for bug 922722 down the road.

The changes are localized to sync.js. Since some of the changes were just some indentation, it may help to pass `?w=1` to the pull request URL so that white space changes are not included.

Also, the finishSync work used to be at the end of the oncronsyncstart callback, but is now at the top so it can be used if there are no updates that need notification.

Since a few pieces of information are needed to properly construct a notification (need to grab appSelf info for the icon, the current account, and any existing notifications), a fetchEnvironment method has been introduced to grab those things.

The work of `makeNotificationDesc` is now mostly in `topUniqueFromNames` since some name deduping in the notification needs to be done. `topUniqueFromNames` is focused purely on a data structure creation, with the final display and use of mozL10n.get('senders-separation-sign') done inline now in the final notification construction.

The notification icon URL, with its encoded dataString, now tracks the names that show up in the multiple email notification, so that if a later notification needs to update the count to include the old notification count, the names can also be used in the updated notification if the new notification list is not long enough. A \n was used for the data separator for this new data in the dataString, comments about it are inline in the changeset.
This is screaming at me "subtle but frustrating upgrade bug" if we get notifications that a previous release of our software generated.  I think we should have some means of guaranteeing that we never have to process the data in that edge case.

A simple way that jumps out at me is for us to prefix our query-encoded object with a single character (or fixed-length string that won't collide with our current encoded values) that serves as our version marker.  If it's not the same as what we're using now, we call Notifications.clear to nuke the existing ones and then return an empty list.  A digit would work for now.

We could also depend on some other more general persisted mechanism; but I think that would be the cookie cache at this time, which introduces other horrifying edge cases.