Add security fix for /../ path expansion

### Problem

Sprockets::Environment#find_asset does not properly expand paths that contain things like "/../", thus potentially allowing to access assets that are outside of Sprockets::Environment#paths.

This is particularly dangerous in combination with [asset_data_url](https://github.com/rails/sass-rails/blob/ae7e785e67986389195067ba990653ebb5829b32/lib/sass/rails/helpers.rb#L27) from sass-rails when compiling user-supplied SCSS input.

An attacker could use the following SCSS to read arbitrary files on the server:
```scss
body {
  background: asset-data-url('/somewhere/rails/app/assets/stylesheets/../../../config/secrets.json');
}
```

### Example

Allowed paths could be ["/foo/bar/"] and find_asset could be called on "/foo/bar/../asset". Since the [validation](https://github.com/fw42/sprockets/blob/43c55841e55ef5894421c45f1ed62bc22240aec3/lib/sprockets/path_utils.rb#L90) is a very simple ```if subpath.start_with?(path)```, this will go through, since "/foo/bar/../asset" does start with "/foo/bar/", even though it's not located in the /foo/bar/ directory.

### Solution

Call [Pathname#cleanpath](http://www.ruby-doc.org/stdlib-1.9.3/libdoc/pathname/rdoc/Pathname.html#method-i-cleanpath) on the paths.

### Review

Please review @sstephenson @josh
cc @rafaelfranca @arthurnn for sass-rails opinions
cc @ibawt @cjoudrey @einstein-
For 3.x, I'm probably going to rework this a little. `Pathname` is terrible on performance which is why its almost been entirely removed on this branch.