Remove more #includes from Frame.h

Remove more #includes from Frame.h

Merges http://trac.webkit.org/changeset/148545 from Sam Weinig.

The idea is again that this improves compile time, as Frame.h is
a frequently included header.

BUG=none
TBR=eseidel (who said "this change sgtm" on the review)

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=148612

[Nico, 2013-04-17 05:30:05]

r?

More of https://codereview.chromium.org/14323004/

I like to write one more CL like this, then I'll compare build numbers of trunk
vs all three CLs applied.

[Nico, 2013-04-17 05:30:17]

(and I won't land any before I have numbers)

[eseidel, 2013-04-17 06:17:38]

When I last tried to do this in the https://bugs.webkit.org/show_bug.cgi?id=3761
bug tree, I remember facing resistance (maybe on WebKit-dev?) about runtime perf
problems that these inlines were optimizations for.  I suspect that's FUD, as
these shouldn't be hot, but we should still take a peek at the perf bots after
this lands.

[eseidel, 2013-04-17 06:18:46]

I'm excited to hear your compile perf numbers.  This changes sgtm.

https://codereview.chromium.org/13976008/diff/2001/Source/WebCore/page/Frame.h
File Source/WebCore/page/Frame.h (right):

https://codereview.chromium.org/13976008/diff/2001/Source/WebCore/page/Frame....
Source/WebCore/page/Frame.h:249: return m_animationController.get();
This is the only one I could imaging being at all hot.  But I suspect any
animation which is hitting WebCore has much larger bottlenecks than this. :)

[Nico, 2013-04-17 20:01:56]

Can i get a formal "lgtm" please?

[Nico, 2013-04-18 04:04:10]

(…and the promised perf numbers are at
https://codereview.chromium.org/13926016/)

[Nico, 2013-04-18 04:07:49]

Committed patchset #3 manually as r148612 (presubmit successful).

[eseidel, 2013-04-18 05:10:56]

lgtm