Remove hack in HTMLParserScheduler for deferring to layout while parsing.

This code was intending to make sure that layout() timers get
a chance to fire before parser timers do.  However we no longer use
SharedTimer for schedulingLayout.  Instead we use the compositor's
scheduleAnimation timer which is only called when the compositor
actually is going to put up a frame.

I could imagine scenerios whereby a layout was scheduled and either
was called and didn't clear the m_pendingLayout bit due to
the Document being inactive or some other early-return, or a scenerio
in which a layout was scheduled but the compistor never needed to
put up a frame, which would result in the Parser spinning like this
waiting for the layout timer to fire and clear the m_pendingLayout
bool, but it never happened.

As the FIXME said, the real fix here is to reduce the max duration
of the parser and possibly coordinate with the compositor to allow
the parser to do work directly after the frame has been put up, in
the time when the main-thread is otherwise idle waiting for the
compositor and gpu threads to actually put up the frame.

This may cause a regression on SpeedIndex benchmarks and we may
need to find a different way to implement what this code
was trying to do.

I was not able to produce a test which triggered this bug, but I'm
confident it's possible to get Blink into such a confused state.

BUG=288265

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

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