Enable MQ evaluation off the main thread

This change came to simplify media query evaluation inside the PreloadScanner, and enable future resource preloading without going through the main thread.
I've listed possible improvements to this code below, but I'd like to have it reviewed before I continue work on it.

Major changes:
* Added a MediaValues class that "freezes" the various media values needed for MQE when it is initialized
* Removed use of AtomicString from MediaQueryExp, to make it thread-safe
* Initialize MediaValues and provide them to the PreloadScanner during its initialization
* Run MQE inside the PreloadScanner, according to provided MediaValues
* Removed mediaAttribute passing to the HTMLResourcePreloader

Possible improvements:
* The added code in MediaQueryEvaluator.cpp can be DRYer. It also adds a lot of conditional statements that may be refactored out later on.
* More tests can be added and especially MQ feature specific tests. (Only min/max-width are tested ATM)
* Turning MediaQueryExp thread-safe was done by simply eliminating all AtomicString in favor of String. I'm not sure this is the proper way to do that, and if it creates performance implications. It may need refactoring.

[Yoav Weiss, 2013-07-05 18:26:40]

Hi,

I'd highly appreciate a review of this change, which enables MQ evaluation in
the PreloadScanner.

I've listed rune and eseidel as reviewers since I've discussed this change with
them, and johnme since it involves a lot of the MediaQueryEvaluator code.

Thanks!

[darktears, 2013-07-08 12:56:23]

On 2013/07/05 18:26:40, Yoav Weiss wrote:
> Hi,
> 
> I'd highly appreciate a review of this change, which enables MQ evaluation in
> the PreloadScanner.
> 
> I've listed rune and eseidel as reviewers since I've discussed this change
with
> them, and johnme since it involves a lot of the MediaQueryEvaluator code.
> 
> Thanks!

Do you have some benchmarks on the benefits of this solution? In general, I'm
not sure if CSS parsing is a bottleneck so far, I believe we have more
low-hanging fruits in Blink before we put the CSS parser in a thread. Sure your
solution puts it for the media query code only but I'm wondering what in the
media query code parsing is so slow (so blocking the main thread) so that we
need to put the CSS parser in a thread. I haven't look the MQ code but I would
expect some experts to comment here. Anyway it's important to have a benchmark
(and maybe add one in PerformanceTest) so that it will convince the people on
whether the solution is good or not.

[abarth-chromium, 2013-07-08 15:12:31]

https://codereview.chromium.org/18328028/diff/1/Source/core/css/MediaQueryExp...
File Source/core/css/MediaQueryExp.cpp (right):

https://codereview.chromium.org/18328028/diff/1/Source/core/css/MediaQueryExp...
Source/core/css/MediaQueryExp.cpp:196: || m_mediaFeature ==
MediaFeatureNames::maxAspectRatioMediaFeature;
not lgtm

We use AtomicStrings here for two reasons:

1) To make these comparisons fast.
2) To save memory by reducing duplicate strings.

[Yoav Weiss, 2014-03-17 12:19:20]

Replacing this CL by https://codereview.chromium.org/201813002/
Closing.