Since 4611:2b6cb7528409 responses from the gzip static, flv, and mp4 modules
can be used with subrequests, though empty files were not properly handled.
Empty gzipped, flv, and mp4 files thus resulted in "zero size buf in output"
alerts.  While valid corresponding files are not expected to be empty, such
files shouldn't result in alerts.

Fix is to set b->sync on such empty subrequest responses, similarly to what
ngx_http_send_special() does.

Additionally, the static module, the ngx_http_send_response() function, and
file cache are modified to do the same instead of not sending the response
body at all in such cases, since not sending the response body at all is
believed to be at least questionable, and might break various filters
which do not expect such behaviour.

In contrast to on-the-fly gzipping with gzip filter, static gzipped
representation as returned by gzip_static is persistent, and therefore
the same binary representation is available for future requests, making
it possible to use range requests.

Further, if a gzipped representation is re-generated with different
compression settings, it is expected to result in different ETag and
different size reported in the Content-Range header, making it possible
to safely use range requests anyway.

As such, ranges are now allowed for files returned by gzip_static.

The h->next pointer properly provided as NULL in all cases where known
output headers are added.

Note that there are 3rd party modules which might not do this, and it
might be risky to rely on this for arbitrary headers.

If response is gzipped we can't recode response, but in case it's not
needed we still can add charset to Content-Type.

The r->ignore_content_encoding is dropped accordingly, charset with gzip_static
now properly works without any special flags.

With "always" gzip static returns gzipped content in all cases, without
checking if client supports it.  It is useful if there are no uncompressed
files on disk anyway.