Investigated how many parser waits occur when the OptQ fills up. The
current implementation has 64k entries, which for 10Mb examples, never
fill up (but do come close to filling up).

To test, I dropped the queue size down. The numbers I got was that the
queue size plus the number of parse waits was within 2% of the total
number of function blocks. Hence, once OptQ fills up a lot of slow
notifies get applied.

Hence, for scaling, I modifed the code to not wake up the parse thread
(during a pop) until OptQ got half empty. The results were that once
the Opt got up to size 1024, less than 100 notifies would be
issued. From 1024 on, as the queue size doubled, the number of
notifies would drop roughly in half.

Based on this, I decided to add the feature that the OptQ did not wake
up the waiting parse thread until half empty. Since the queue size was
not shrunk, this CL shouldn't add any overhead for the PEXES we have,
and very few waits with significantly largers than the current (10Mb)
PEXES.

BUG=None
R=jpp@chromium.org

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