Rename REMOVE_COOKIES to REMOVE_SITE_DATA (which will explicitly include REMOVE_LSO_DATA).
There's no case in the current codebase when we want to remove _only_ LSO data, and no case where we want to remove cookies, but _not_ LSO data. There are many instances of building removal masks that binary-OR REMOVE_LSO_DATA and REMOVE_COOKIES together; this CL formalizes that by dropping the extra enum value.
Moreover, we talk about "cookies" differently when targeting users on the one hand, and developers on the other. REMOVE_COOKIES is a developer-facing name with a user-facing value, which is confusing. Renaming the current functionality to REMOVE_SITE_DATA is much more explicit, and will enable us to _just_ remove cookies at some point in the future via a REMOVE_COOKIES that actually means cookies.
REMOVE_SITE_DATA has exactly the same semantics that REMOVE_COOKIES used to, with one exception: REMOVE_COOKIES included deleting cached strict transport security values. This functionality has been moved to REMOVE_CACHE.
As a drive-by, this CL also moves a check against the kClearPluginLSODataEnabled pref out of webui (ClearBrowsingDataHandler) and into the BrowsingDataRemover itself, where it seems more likely to be effective.
TEST=Nothing but removal cached transport-security values should change.