inlineEditor worked alright in most of our previous cases, but while

investigating some issues today, I realized it just wasn't as smart as

it should be.
When figuring out its ideal size, it was assuming that the input would

have the default box-sizing of content-box. If it was anything else, the

calculations would be off, due to assumptions when calling getExtents().

It now checks before deciding what needs to be called.
It has some new smarts regarding the button size allocation.

Previously, it would assume that if there were buttons, and it's a

single-line editor, that the button widths should be factored in. If

custom CSS places the buttons on the following line, those widths

are no longer factored in.
This also goes back to using `display: none` instead of

`visibility: hidden` for the edit icon. This was intended to keep the

height of the line the same so that the text and the content below it

doesn't jump when the icon is shown or hidden. Instead of doing this,

it's now up to the consumer to pick a line-height that's the greater of

the icon height and the text height, and use that for both elements.

That will keep the text and layout consistent.
Changing how the edit icon is hidden also gives us more space for the

actual field, since we no longer need to make room for the icon (to

prevent wrapping).

Tested all single-line and multi-line inline editors on the review request

page (with an accompanying change to Review Board). Also tested the new one

on the My Account page.
Tested showing and hiding the edit icons manually. Didn't see any page jumps

(again, with the proper CSS changes from the RB change).