Treat invalid fingerprint like no fingerprint

Recently a change was made to check the fingerprint in the URL against the fingerprint of the files on disk. This is pretty great and solves a problem I've been seeing for a while.

We run our app on multiple servers, and during a deploy a user can be served a page from a server with new code, but then be sent to a server with old code to fetch assets. As Sprockets previously didn't validate the fingerprint this lead to old assets being served under the URL of new assets. This is even worse with a CDN in the mix, as then the CDN caches the old asset under the new URL.

It turns out when I finally have the time to fix this problem it has already been fixed for me :smile:
However I don't think the approach of returning a 404 when the fingerprints don't match is quite right. This would mean that any users who hit a not-yet-updated server during a deploy would get a page with no styles and/or no JS at all. It would be better to treat the request like one with no fingerprint, serve up what is available, but set the `Cache-Control` header such that the user's browser/CDN will re-request the file next time rather than using a cached version. This leaves the majority of users who are visiting a page that hasn't been changed in the ongoing deploy with a fully working page.

I've also removed the `if_match` feature from the `find_asset` method, and associated methods/tests, as they were no longer used. If there were plans to use this elsewhere I'm happy to drop that commit.