Support for statically compressed gzip content-encoding

Related to #12 (closed), this MR enables serving precompressed gzip content in GitLab Pages.

To use it, static files that are to be served compressed must be present at the same location as the uncompressed file, with the extension .gz. The uncompressed file must remain present so that:

• HTTP clients that do not nominate an Accept-Encoding of gzip can still receive the content,
• Range requests continue to work, by serving the sliced uncompressed content (otherwise the daemon would need to recompress on the fly),
• The daemon can auto-detect the difference between the compressed variant and, for example, a .tar.gz file which should not have the Content-Encoding header attached to the response. (Otherwise the browser may decompress and present a .tar file to the user.)

The gzipped content must be placed in the same directory as the uncompressed content. When the latter is a symlink, the gzipped content must be placed at the symlink target directory with the same file basename as the target. For example, if the file index.html is symlinked to content/frontpage.html, then the gzipped content must be located at content/frontpage.html.gz. This is both to co-locate the gzipped content with the uncompressed variant and to simplify the implementation.

Directory index.html files and the /404.html files can also be compressed by having corresponding index.html.gz and /404.html.gz compressed variants.

HTTP HEAD requests continue to work correctly; the Content-Encoding header is also applied as appropriate, so that HTTP clients can know that they may receive compressed content in that case.

I am keen to see this merged and deployed to GitLab Pages so that my (and everyone's) static sites load much faster: HTML, CSS, and JavaScript as you know often compresses with very high ratios. I'm sure GitLab Inc. would enjoy the bandwidth (cost) savings too.