Use precacheHash in the config file in lieu of a precache URL param

[jeffposnick]

R: @wibblymat @addyosmani

This PR is blocked on GoogleChromeLabs/sw-toolbox#24, but I've tested it locally with a hack to flatten the array, and it seems to work. It shouldn't be merged until a new sw-toolbox release is cut.

Once this PR is merged, I expect to tag a 1.2.0 release of platinum-sw, and then I'll put together a related PR against https://github.com/PolymerElements/polymer-starter-kit to account for the new way of doing things.

This closes #53

[jeffposnick]

(The No match in Cache Storage API for http://localhost:2000/components/platinum-sw/test/platinum-sw-cache/file.html: expected undefined to be truthy failures in the CI tests are due to GoogleChromeLabs/sw-toolbox#24)

[wibblymat]

A minor comment mistake here: I believe that you mean the precacheHash is present in the querystring options, rather than in the JSON.

[wibblymat]

Oh, nevermind - it comes to here through the options, but is of course originally in the JSON.

[wibblymat]

As I understand it, the value of precacheHash can be anything, and in order to be useful it only needs to be some different value each time you need the service worker to be re-installed. So you could use a version number, the commit hash of the latest git commit for your site, a hash of the array, a hash of the files themselves, the timestamp of the build, etc.

I wonder if it would be better to be more open/general about how this is described so that developers understand they can use whichever option works best for them. There are several situations that the hash of filenames method wouldn't handle well. If a file changes but has the same name, for example.

On the other hand, most of the easy/lazy ways people might choose have bad problems too, so I don't want to encourage them.

If we change the way it is described, we should also consider renaming the option. Perhaps something like fingerprint?

[jeffposnick]

Thanks, @wibblymat. PTAL.

[wibblymat]

Awesome