Bug 1064617 - (email-rtl) [META] [RTL] Email

Generally improves the RTL situation in email. Changes were the following:

## Move to flexbox

For some pieces, they were moved to flexbox, away from floats. The attachment UI in compose and message_reader most notably. Also, the settings items where there is text on one side and a control on the other (.list-text-pair changes).

## Background position

Most of our icons use a background image, and some are edge-aligned, so those needed overrides for background-position.

## Some floats stayed

Some of the floats stayed, so they have a dir="rtl" override. These were cases where the floated piece was more ornamental, like a "selected" dot or simple icon to describe the text. The decision to go to flexbox or stay as a float with a CSS override was based on how many elements in the row were involved, and if they were actionable or more ornamental, or if it was already a more complicated setup, and I did not want to mess with it much, like bubbles in relation to text entry in the compose address envelope area.

## dir=auto additions

If the text could have come from a user, instead of application UI text, dir=auto was added to allow proper text display. For most purposes in email, this meant for single line text displays, that the ellipsis truncation would happen correctly.

## Specific uses of -left -right used

These cases were if dir="auto" text was being displayed, but it was typically smaller than the display region for it. In those cases it was more important to have the text right align, to match the rest of the right-aligned UI grid in the RTL case, than have the ltr text floating off to the left, breaking the flow.

This was done just for display areas, not text inputs.

### iframe_shims

This one will need more work, but this initial change just gets the email to show up correctly. It is messy though, and I expect this to change, tracked in bug 1099449.

**Summary**: This is just to get a baseline set up. More changes will be needed, but at least now the email app does not look like a graphics rendering glitch in rtl mode.
for my translated puppies.jpg example, I'm seeing vertical sizing overflow issues when there is only the one attachment.  the cmp-attachment-fileinfo ends up with a clientHeight of 40 but a scrollHeight of 48 (which visibly overflows, of course.)  filename ends up with a clientHeight of 31 (4 padding-top, 27 height) and filesize 17.  This causes them to overflow the margin line we put beneath the attachment section.

The problem almost goes away when we have multiple items, but that's because the .cmp-attachment-container li:last-child rule gives us 0.6rem of space.  It's not quite enough because the 172"X" mirror K has a little foot that just crosses the line.

It looks like the root problem might be that we seem to be getting our sizing info for the row from .cmp-attachment-icon which has an explicit size of 4rem set.

If I change -fileinfo to use a "display: flex; flex-direction: column;" the -filename goes to 4 padding-top, 22 height, I'm assuming since -filename is no longer meaningfully a display: block in flow.  I think there may then be complications since -filename and -filesize have overflow: hidden in general set.

I think there are various complications, but basically I'm wondering if we should do something like move to flex-box here too.  And I mean I'm genuinely wondering... It's not clear to me whether having line-heights potentially have more explicit control is a benefit or a curse, especially since we're micro-managing layout in so many of these cases.