redesign based on newer W3C specifications

[jokeyrhyme]

Ideas for a redesign:

• implement Node.js-specific network and storage adapter as a separate "w3c-cache-via-node-fs" project
  • worth extracting out "unique-filename-from-w3c-request" project, to be used elsewhere
  • provide an alternative "w3c-cache-via-cordova-file" project, for Cordova use
  • provide an alternative "w3c-cache-via-localforage" project, for browser use (LOW PRIORITY)
• require the W3C cache object to be provided at runtime by consumers
• possibly extract transformation work out into separate project
  • such a project would need access to the same Cache object in order to operate correctly

By focusing on interchangeable Cache implementations, we gain increased portability for the rest of the code (e.g. transformations, etc). Apps that need dynamic lookups can be written against the standard Cache API and will be more compatible with Service Workers in future.

The increased portability should help with construction of a "cordova-plugin-evergreen" project that can be used to safely update the contents of a Cordova app's www/ directory at runtime.

[jokeyrhyme]

W3C specification for Service Workers and the Cache API:
http://www.w3.org/TR/service-workers/#cache

[jokeyrhyme]

This project provides the W3C Fetch API within a Node.js environment:
https://github.com/bitinn/node-fetch

If the "w3c-cache-via-node-fs" project used this, then we'd be able to share even more code between the different Cache adapters.

[jokeyrhyme]

Should consider the ramifications of switching to a different directory structure. Instead of scrambling filenames in order to keep output in a single-depth directory, what if we could preserve the directory structure of the original content somehow?

• e.g. output_dir / origin / same / path / as / remote / resource.js