LiveNodeListBase code should not need to worry about id/name cache invalidation

LiveNodeListBase code should not need to worry about id/name cache invalidation

LiveNodeListBase code should not need to worry about id/name cache
invalidation. Previously, LiveNodeListBase::invalidateCache(QualifiedName) would
explicitly handle the case where the nodelist has a id/name cache (i.e. it is
an HTMLCollection) and then invalidate it.

The following changes were made to avoid this:
- Add invalidateCacheForAttribute() methods to HTMLCollection and LiveNodeList
  classes and let them handle cache invalidation. HTMLCollection's method is
  the only one that takes care of invalidating the id/name cache if needed.
- The invalidateCacheForAttribute() method in LiveNodeListBase calls the
  corresponding method on the right subclass using the m_collectionType member.
  We could make it virtual but cache invalidation can be hot and this causes
  slight regressions in Dromaeo.
- Remove any traces of id/name caching from LiveNodeListBase.
- Use DEFINE_TYPE_CASTS() macro to define casting functions for HTMLCollection
  and LiveNodeList, so that we no longer need to do manual casting.
- LiveNodeListBase no longer needs to be a friend class of HTMLCollection.

Also, the method was renamed to invalidateCacheForAttribute() for clarity and
to distinguish it better from the invalidateCache(Document*) one.

I see no performance regression on Dromaeo DOM tests:
http://dromaeo.com/?id=220318,220326

R=esprehn@chromium.org, adamk@chromium.org

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

[adamk, 2014-04-24 00:14:33]

lgtm

[Inactive, 2014-04-24 01:09:52]

The CQ bit was checked by ch.dumez@samsung.com

[commit-bot: I haz the power, 2014-04-24 01:10:10]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/247263008/20001

[commit-bot: I haz the power, 2014-04-24 02:58:03]

Change committed as 172440