Handle Response objects in cache resolution and in RESTful responses

[kriszyp]

This provides improved handling of Response and Response-like objects in cache resolution and REST responses, addressing CORE-2576 and CORE-2596. This is intended to make easier to setup direct/transparent HTTP caching with minimal work, as simple as:

tables.MyCache.sourcedFrom({ get: (id) => fetch(`https://origin.com/${id}`) });

The cache resolution should properly handle the Response object, branching on status codes, storing headers, and if the response is something that can be parsed, is stored in structured data format, if not, it is stored in a blob.
There are more expansive ways this can be used to define your headers and data and such, and example usages can be seen in the testApp/resources.js that is used by the tests.
This also broadens the types of responses that the REST handler will treat differently. Previously only a combination of status and headers properties triggered special response handling, but now the REST handler will honor any object with headers properties as having headers that should be returned in the response (along with more granular logic for data/body). It actually should be more common (or encouraged) to return headers than status.
Also this introduces ambient access to the current "response" object, allowing code to generally set response headers or status like:

import { getResponse } from 'harper';
... from anywhere:
getResponse().status = 201;
getResponse().headers.set('Location', 'someplace new');

Thoughts on the ergonomics of this are certainly welcome also.