Handle 304 caching for checkReleases

[guybedford]

Because caching.

[crisptrutski]

Implementing the obvious ETag based caches for getPackageConfig and checkReleases. locate is trickier - the current implementation uses the website, which does not seem so support If-Modified-Since or If-None-Match.

Will try out a solution where /users/<owner>/repos/ is cached and used for these lookups. Since this will leave us blind to repo renames, we'll still fail over to the website call (which is still indeterminate - and may fall through to lookup to reject).

Cannot see any way to cache lookup - ls-remote doesn't seem to provide any quick check for changes. That's OK because probably most time is spent in negotiation and calculating and sending the heads is probably negligible.

No cache required for downloads - lean on JSPM cache there

[guybedford]

There are three large requests here: checkReleases, locate and ls-remote for lookup. As @crisptrutski notes, we can't cache ls-remote unless we internally implement the git request, so that's blocked on #25. lookup can actually now be handled via #54, so that just leaves checkReleases as the main thing to cache here.

Renaming title to match.