Repaint-after-layout ASSERTs with nested layouts

What would happen is that:
- the inner layout would call repaintTree, thus clearing everything.
- the outer layout would call repaintTree on a cleared tree, thus
exploding.

While this shouldn't have caused user visible issue, it was
inefficent. The fix is to ensure that we only ever call repaintTree
for the outer-most layout, this requires to refactor the existing
code to properly handle nesteds layout instead of generating some
extra repaints.

BUG=320139

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

git-svn-id: svn://svn.chromium.org/blink/trunk@167044 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Re-land "Don't check lfQuality in LOGFONT as it has no effect on rendering""

Re-land change r163507, reverted as r166868 but include a cache for the
text flags, as before the original change, to avoid the performance
penalty that forced us to revert the original change in the first
place.

Remove the LOGFONT lfQuality check in computePaintTextFlags and instead
base the textFlags entierly on the system ClearType settings (and
whether a font is a web font). Skia will then use this information to
pick the appropriate type of font smoothing to apply (if any).

BUG=249099
R=bungeman@chromium.org, leviw@chromium.org

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

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