Bug 985598 - [email] Double-triggering of share/new activity by clicking...

This change converts all ConfirmDialog uses to be backed by a card insertion instead of the document.body appendChild approach, which made it harder to clean up/reset state for those cases. That new ConfirmDialog is then used in place of the confirm() in the activity flow. This allows for cleaner app reset and avoids the double triggering of activities from freaking out the email app.

Some notes:

* With this change, it is possible for toast banners to appear in front of the ConfirmDialogs as the ConfirmDialogs are now in the card stack.
* The compose card needed a fix for when the compose card is destroyed very quickly when the email app speculates that compose should be the start card for the activity. I believe this is needed now there is no longer a confirm() that is blocking part of the flow. It seemed like a good fix to have in general too.
* There are two styles for calling ConfirmDialog.show: the old way, so that the rest of the ConfirmDialog references did not have to change, and a newer, simpler way that mimics the style of a confirm() dialog, with just a message that can be customized.
* No new l10n strings, but the simple confirm dialog uses l10n ID "message-multiedit-cancel". While not ideologically pure, other dialogs were already using it, so seemed safe to do so here too, although long term, each one of those cases should have its own cancel, or convert more of the code to use the simple ConfirmDialog approach.

It may make sense to file a separate bug to track cleaning any alert() usage to use a similar approach to this one, and then also perhaps a more invasive change that converts ConfirmDialog.show() calls to be more like the simpler approach, with maybe some more config options like button titles and styles like "danger" used in some ConfirmDialogs now.

I still may need to fix some things in the integration tests, but had trouble running them locally, so will look at it more tomorrow and the Travis result against all the tests. Thought I would start this pull request though as the approach may still need some discussion.