fix: return a more-complete 304 from TransformingTransport.RoundTrip

to address the segfault we're seeing in production. The necessary
conditions for the issue are:

1. The 303 must return a location URI that changes every time, so that
   the real location of the image is never cached. As an example, if the
   remove service redirects to S3, the presence of the
   `X-Amz-Security-Token` accomplishes this.

2. The image responses must match by Etag, so that
   imageProxy.should304() returns true causing
   TranformingTransport.RoundTrip() to return a bare 304 response.

If those conditions are met, then the bare 304 Response returned will
be used and read by one of the callers. Specifically, the lack of a
Body causes a segfault.

So let's make it more like a real Response and use http.NoBody so when
it's used it doesn't cause things to explode.

.github/workflows: drop linux/arm/v7 from docker

I believe chainguard no longer supports arm/v7.  This was added at a
user's request I think that was running imageproxy on a raspberry pi or
something.  I might switch to a different base image that does have
support, though it's annoying to have to do so.  In the meantime, users
can always built the image themselves for other platforms.

docs: update install instructions for both go and docker

docker: remove envy go.mod file

bump docker build to go1.17, and actions to latest

docs: update changelog in preparation for v0.10.0

0.9.0 release

add a changelog

readme: move badges below title

bump to 0.6.0