Chrome doesn't garbage-collect (or even leaks) SVG <symbol> referenced via <use> so we'll embed the code directly on manage and popup pages where dozens/hundreds of svgs are displayed.
* restore the correct width of svg icons
* popup: use the standard formatting & SVG <symbol>
* popup .breadcrumbs hover highlight
* manage: black links, transitions; use <p> in #options; trim .homepage
* edit: move regexp tester info link to a template
* "Find styles" is a link so we make it one, just like in the popup.
* We have a dedicated global options UI so it makes no sense to subset only two of them on the manage page, moreover both options are unrelated to managing styles.
Previously prefs.set broadcast many messages per each changed pref value to all open tabs, background page, popups. This lead to repeated and needless updates of various things like the toolbar icon, reapplying of styles, and whatnot. It could easily take more than 100ms on an average computer with many tabs open.
Now we debounce the broadcast & sync.set and coalesce all values in one object which is then sent just once per destination.
* Now that our own pages retrieve the styles directly via getStylesSafe the only 0.001% of cases where code:false would be needed (the browser is starting up with some of the tabs showing our built-in pages like editor or manage) is not worth optimizing for.
* According to CSS4 @document specification the entire URL must match. Stylish-for-Chrome implemented it incorrectly since the very beginning. We detect styles that abuse the bug by finding the sections that would have been applied by Stylish but not by us as we follow the spec. Additionally we'll check for invalid regexps.
uBlock-extra rewrites html of some sites known to have bad scripts. Such new documentElement doesn't have our styles so we need to detect this case by observing the parent document node non-recursively, meaning we don't add overhead to the normal browsing experience.
* [x] show badge with active styles count
* [x] styles on top in the popup
* Simplify since we use a persistent background page so it's always there for us
Previously we incorrectly assumed that each sub-element is present in addedNodes array, but actually we need to inspect each added node's children e.g. using the superfast getElementsByTagName.
