use relative asset paths instead of asset specs

Asset specs are cool, because they give us the ability to use paths
which are package-relative without knowing where the package is
installed, but it's not the right solution in our case. By not using
asset specifications here pyramid_webassets is left to figure out
the location of our assets by using the environment configuration in
webassets.

- Makes assets more easily overridable! Add a path to the head of
  webassets.load_paths and override an asset. Voila!
- Makes it possible to leave off the excess static_url routes and
  leave only the webassets URLs. That means that even when serving
  assets "as is" (unfiltered), such as images, the asset prefix is
  used. In production, this will be important since it allows the
  base URI for assets to be absolute (likely on a separate subdomain)
  and be honored everywhere.
- It fixes the cssrewrite filter by ensuring that the base URI for
  the input is considered against the webassets base URI rather than
  the other static view configurations.
set appropriate cache headers for static assets

When webassets is configured to use unique URLs for versioning,
set a "far future" expiration so browsers cache forever. Otherwise,
make sure they don't cache at all because we're in development mode.