Bug 1041904 - [Email] Customize Status Bar Color

Updates status bar color based on card color. Cards does most of the work, but some specialized dialogs need to card the Cards.setStatusColor manually. Longer term, I think it is better to refactor those uses to fit into the Cards more. However, I want to do that work after landing the custom element work.

setStatusColor allows a few different options for choosing the color, see API docs in mail_common. The main goal is to avoid hard coding specific colors in the HTML or JavaScript, except for the meta tag itself, and setting up a default color.

I went with 'status' instead of 'theme' for the APIs and properties, since to me themes could be something different, could be something configured inside that app, and all of this right now is about setting the status bar color. Maybe that changes in the future, and status is too narrowly defined though. Open to renaming if reviewer thinks that helps. Either way, we are probably going to need to rename if in-app themes or some other status thing is introduced, or theme-color used for more than just status.

Also includes a fix for centering the Cancel button in value_selector, that is the common.css change.

The color is set before starting the card transition, since the animation performs better. If done in the transition startup logic, but after transition classes on the cards are set, our animation transition became choppy. If set after our transition completes, the status bar looks lazy, too much out of step with the UI. As it is now, the color fade in the status bar is non-optimal for our "immediate" card transitions, since that UI updates fast, but the status bar color still needs fade time. It was reviewed by UX, so that is what we will go with for now, since setting the color is the only toggle we have for that status bar color. 

I will file follow up bugs related to status bar icon colors (they don't seem to adjust well to some of our color choices) and asking for maybe a "transition immediately, no fade" option. It will help to have this landed though to give a point of reference/reproducibility for those bugs.
Bikeshed API feedback, I don't think there's any need to actually change this: Since data-statuscolor can already accept a special "default" value, it seems like a special "background" value could simplify things control-flow wise since it rules out a lot of pathological situations.  (Ex: what if both things are present for some reason, etc.)  It can also limit the boolean failover so we can more explicitly log that we're setting the color to something because it's a default.


However, it'd be great if you could briefly touch on what the expected performance/layout/restyle implications are of data-statusbg.  My quick impression is that because we're doing this because we're pushing a new card and we do it right before compelling an animation (which forces layout, not just style calcs, maybe worth revisiting that hack), it's basically for free with no hidden surprises.