adds logic to upload compressed files with right mime type and right content-encoding

[sprockow]

Background

##81

Proposed changes

If not specified within the objectHeaders option, uploaded objects are given a content-type header automatically based on their file extension using mime 's lookup function. Unfortunately, this causes problems if you attempt to upload a file with a file extension + a compression extension. ie main.123.js.gz .

Now, there aren't any standards (that I know of ) to reference here, but the common practice that I've seen is that gzip compressed files follow the pattern

*.{file-extension}.gz

and brotli compressed files follow this pattern:

*.{file-extension}.br

I haven't come across anything for other compression encoding types, but I would be happy to add support in this PR

If we assume that users who precompress their file will follow the above described practice, then this merging this PR will do the following:

1. Files matching *.*.br will be given a Content-Encoding header value of br, in accordance with brotli standard
2. Files ending with *.*.gz will be given a Content-Encoding header value of gzip in accordance with gzip standard
3. Files that do not match either above pattern will be passed to the existing logic and given a mime type based on file extension

[sprockow]

Updated README.md and fixed some merge conflicts.

[Shereef]

I would want to do some research to see if there are other encodings we can support like x-tar or x-tar-gz and also understand what deflate is

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding

please allow some times for me to brush up on those topics