Revert of Empty inline elements always get a line box. (https://codereview.chromium.org/300853007/)

Reason for revert:
This changed the subpixel positioning of glyphs on lines with first-letter renderers on Mac builds. See https://storage.googleapis.com/chromium-layout-test-archives/WebKit_Mac10_6/28423/layout-test-results/results.html as an example.

I think the new results are benign - but would like to confirm with leviw and reland as NeedsRebaseline if we're both happy with them.


Original issue's description:
> Empty inline elements always get a line box.
> 
> CSS 2.1 (http://www.w3.org/TR/CSS2/visudet.html#leading) says: "Empty inline 
> elements generate empty inline boxes, but these boxes still have margins, padding, 
> borders and a line height, and thus influence [line-height calculation] just 
> like elements with content."
> 
> We weren't creating lineboxes for empty inline elements when they occurred
> between a single trailing space and a single leading space - this is because
> our linebox creation was based on the too-narrow premise that we were already
> ignoring spaces. However, if an empty inline element comes after a trailing 
> space but before one or more leading spaces then it will be ignored as part 
> of the collapsed space between the trailing space and the next non-collapsible 
> space - so we should force the creation of a linebox in such cases.
> 
> This allows us to pass Hixie's empty inline test: 
> http://www.hixie.ch/tests/evil/mixed/emptyinline.html
> 
> BUG=328939
> 
> Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=175205

TBR=leviw@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=328939

Review URL: https://codereview.chromium.org/302233002

git-svn-id: svn://svn.chromium.org/blink/trunk@175207 bbb929c8-8fbe-4397-9dbb-9b2b20218538