Refactor Remote vs Local Cache

The motivation for this change is to allow artifacts downloaded by RESTfulCache to be directly added to the LocalArtifactCache without needing to decompress and recompress them as we do now.

At a high level, this is done by refactoring RESTfulCache such that it no longer handles creating or extracting tarfiles directly and instead delegates those operations to a LocalArtifactCache instance passed in its constructor, which may store them in the process.

This is a revision of a previous proposal along similar lines, though this iteration has RESTful artifact cache always passed a LocalArtifactCache at construction, to which it can always delegate all local file interaction (tarfile creation and extraction)

This simplifies RESTful cache, reducing it to only the HTTP-related functionality. This also eliminates duplication of tarfile creation and extraction logic, which now justs lives in the LocalArtifactCache.

TempLocalArtifactCache provides an alternate implementation of LocalArtifactCache, backed by tmpfiles instead of a cache_root. This can be passes to RESTfulCache to handle artifacts when running in a remote-only cache configuration.

Notes:

This change removes all usage of CombinedCache -- the only case where it was used,
composing an HTTP and local cache, is covered by the above changes.

It also removes the  "backfill" behavior from CombinedCache, which only made sense in the above setup: two remote caches should likely use rsyncd or whatever to share files rather than relying on clients building to shuttle artifacts between them and local caches can use symlinks or mounts.

Caches also now use stdlib logging instead of context.log since the latter
has references to the runtracker making it almost impossible to pickle.

Caches now use string.format instead of % for composing log messages.