This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:

• Filters
• Shapes and images, almost. Need to:
  • Get rid of the complex -moz- gradient parsing (let layout.css.simple-moz-gradient.enabled get to release).
• Counters, almost. Need to:
  • Share the Attr representation with Gecko, by not using Option<>.
    • Just another variant should be enough (ContentItem::{Attr,Prefixedattr}, maybe).

Which in turn allows us to remove a whole lot of bindings in followups to this.

The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:

SpecifiedUrl
 * CssUrl
   * Arc<CssUrlData>
     * String
     * UrlExtraData
 * UrlValueSource
   * Arc<CssUrlData>
   * load id
   * resolved uri
   * CORS mode.
   * ...

The new one removes the double reference to the url data via URLValue, and looks
like:

SpecifiedUrl
 * CssUrl
   * Arc<CssUrlData>
     * String
     * UrlExtraData
     * CorsMode
     * LoadData
       * load id
       * resolved URI

The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.

I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).

The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.

One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).