Fix several size-related issues in inlineEditor.

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).

Reviewed at https://reviews.reviewboard.org/r/6172/
Allow greater control over inline editor buttons and rendering.

The buttons element is no longer always a <div>. If it's a multi-line
editor, it will appear as a <div/>, but if it's a single-line editor, it
will appear as a <span/>. This is preferred over hard-coding a
`display: inline` style on the element, and will have the same effect by
default. Custom CSS can then override it to have whatever display style
is appropriate.

There are also cases where a caller may need to set some properties on
an element before actually showing the editor and triggering the layout
code. For example, an element may need to be set that would impact the
positioning of the buttons or some other aspect of the editor.

To handle this, there's now a beginEditPreShow event that callers can
listen to. This is displayed immediately before the editor is shown.

Reviewed at https://reviews.reviewboard.org/r/6173/