Performance improvements for nsIFrame

[classilla]

nsIFrame and descendants can slow down layout substantially by requiring some unnecessary work. Not all of the subsequent improvements have been identified in the QF summaries.

M1381157 looks like it generally applies: https://hg.mozilla.org/mozilla-central/rev/97a042be82e5

Following that, we do still have some NS_FRAME_* bits left, so we could do that for M1205475 which includes both the frame bit caching (but we use NS_FRAME_... instead of EffectSet) and reorganizes some of the hot functions M1381157 speeds up.

[classilla]

https://bugzilla.mozilla.org/show_bug.cgi?id=1205475

[classilla]

(and then don't regress http://kwan.perix.co.uk/mozilla/blinkTest.html , from bug 1406211)

[classilla]

This is only peripherally related, but there are some caching optimizations we're missing out on.

https://bugzilla.mozilla.org/show_bug.cgi?id=1344398 looks like it applies.
The 1 << 26 bit comes from https://bugzilla.mozilla.org/show_bug.cgi?id=1227327 which involves a DLBI change that was backed out of 45, so we shouldn't take it here right now.

[classilla]

Also, https://hg.mozilla.org/integration/mozilla-inbound/rev/cc19d7604b6e

[classilla]

1205475 requires some major surgery I'm not comfortable with in nsIFrame and the nsLayoutUtils acceleration is called very infrequently. Wontfix.

[classilla]

1344398 craps out and makes the browser hang on startup. It's too much of an edge case to make smoking it out worth it. Nothing else to do here.