Address comments on Gzip implementation

- don't mutate PATH_INFO in env, test
- test fallback content type matches Rack::File
- change assertion style
- make HTTP_ACCEPT_ENCODING comparison case insensitive
- return gzip path from method instead of true/false so we don't have to assume later
- don't allocate un-needed hash.

Original comments:

https://github.com/rails/rails/commit/cfaaacd9763642e91761de54c90669a88d772e5a

cc @jeremy
I ran some benchmarks. For an asset that does not have gzip if we never stat it the second time it looks something like this:

```
Calculating -------------------------------------
           Gzip; Now       490 i/100ms
  Gzip; No gzip Stat       515 i/100ms
-------------------------------------------------
           Gzip; Now     5076.2 (±6.1%) i/s -      25480 in   5.040338s
  Gzip; No gzip Stat     5352.6 (±6.7%) i/s -      26780 in   5.027866s
```

Which is  `100 * (5352.6 - 5076.2) / 5076.2 #=> 5.445017926795646` or roughly 5% faster. by not doing the second stat. This "tax" will only happen on requests to a valid asset (verified earlier in `match?`) It will also only occur one time for each asset if you're properly using a CDN, or never if you're using NGINX. `<opinion>`If you don't care enough to put a CDN in front of your assets, you probably don't care about 5% on a 200ms asset request `</opinion>`.

That being said, we could cache this stat in memory. There are threading issues, and if you're doing something silly like dynamically storing images and serving them from your disk then we've created the ability to create a very large object. I'm not a big fan of this, now we're kindof acting like a poor-person's CDN.

Turning on/off the ability, we already have the ability to turn off static asset serving all together which would turn this feature off :grin: Personally i'm already suffering from `config.whatever` overload.

Deducing content type is a really clever idea, I hadn't thought of that before. There may be some edge cases, perhaps someone is using a `svg.gz` instead of a `svgz`, but the wins likely outway the costs of any files that fall through the cracks. If you're not comfortable with the 5% tax on non-gzip assets, I think this is the way to go.