Add UseCounter for case-insensitive attribute value selector matching

Source/core/frame/UseCounter.h

Index: Source/core/frame/UseCounter.h
diff --git a/Source/core/frame/UseCounter.h b/Source/core/frame/UseCounter.h
index aa08ad5d3faadf741e083bfa14f3cceb41034e6b..68e43b76ce513465af9b75ab9363eae80ce85182 100644
--- a/Source/core/frame/UseCounter.h
+++ b/Source/core/frame/UseCounter.h
@@ -298,6 +298,7 @@ public:
         PrefixedTransform3dMediaFeature,
         PrefixedAnimationMediaFeature,
         PrefixedViewModeMediaFeature,
+        CaseInsensitiveAttrSelectorMatch, // Case-insensitivity dropped from specification.

[Mike West, 2014/01/23 09:22:54]

I'd suggest adding a counter for attribute selectors in general, so that we have
something to compare against. Right now, it'll be tough to answer the question
"What percentage of calls will this change effect?"

[Jens Widell, 2014/01/23 09:38:49]

I'm not 100 % sure how use counters work, but won't this counter alone answer
the question "how many page loads had at least one selector whose behavior would
change?"?  Do we need to know how many page loads were not affected because they
had no attribute selectors vs. how many page loads were not affected because
their attribute selectors were not case-insensitive to begin with, or were but
matched even without case-insensitivity?

I don't mind adding additional use-counters, of course, but I guess they (too)
would carry a slight performance cost in matching attribute selectors.

[Mike West, 2014/01/23 10:08:24]

I'd suggest that there are two relevant numbers:

1. The percentage of total page loads that this change would affect: that's the
number the counter you're adding gives us.
2. The percentage of page loads that contain selectors which would be affected.

If, for example, #1 was 0.002%, but #2 was 100% (low penetration of a feature,
but every use is broken), we might approach it differently than if #2 was 0.02%
(high penetration of a feature, low impact change).

Does that make sense?

[Jens Widell, 2014/01/23 10:27:21]

How would you define 2?  A case-insensitive attribute selector is

 A) parsed in a stylesheet
 B) checked against an element
 C) checked against an attribute value
 D) something else?

Option A would probably be performance neutral, while B/C would increase the
performance impact of this patch somewhat.

         // Add new features immediately above this line. Don't change assigned
         // numbers of any item, and don't reuse removed slots.
         NumberOfFeatures, // This enum value must be last.