Fix content encoding header being set to "identity"

[hhromic]

The actual problem was the case of serving an identity file without any compressed siblings.

For example if the content directory contains:

file.txt
file.txt.gz
file2.txt

• Requesting /file.txt or /file2.txt without gzip gives no Content-Encoding header (no accept-encoding -> returns the base file directly without further processing)
• Requesting /file.txt with gzip gives Content-Encoding: gzip (returns basefile + .gz)
• Requesting /file2.txt with gzip gives Content-Encoding: identity (returns baseFile)

The last case was incorrect behaviour, response should have no content-encoding header.

The fileserve test code was fixed and improved to cover for this case.

Fixes #10

[hhromic]

@lpar thanks for merging this PR. I can confirm now that combining lpar/gzipped with nytimes/gziphandler in a hierarchy of handlers works perfectly in version v2.0.2.

Any file request that does not have a pre-compressed file on disk served by lpar/gzipped can be compressed on-the-fly with nytimes/gziphandler just by chaining these two modules.