Adding contentType cli option to address #276

[howardroark]

fixes #296, fixes #276

[Jameskmonger]

Hey @howardroark, couple of linting issues on this failed the CI build.

[howardroark]

Thanks @Jameskmonger ! Fixed ;)

[borisirota]

@Jameskmonger Hi, will this be merged ?

It is very useful in my case where I have static website and prefer the urls to be of a form /about without the extension /about.html.
The files are saved in the file system without the extension but need to be served with the correct Content-Type in order to be parsed correctly.

Just a small note, its not very correct that Use a custom Content-Type response header for all requests.
As I see in the ecstatic source code, the --contentType param is being used only if the mime.lookup fails. IMO its great because it means that this param is a fallback rather than override of expected behavior (e.g. override the Content-Type header of a javascript file to html file's content type).

[thornjad]

We should match the style of other switches by using --content-type

[thornjad]

The contentType option actually is used for fallback, so maybe we could clarify by saying something like "Default Content-Type if it cannot be determined"?

[thornjad]

possibly even more clear, though a long option, --default-content-type?

[thornjad]

I know this PR is a few years old, @howardroark I can take this over if you'd like me to

[mmahut]

Oh boy.

[KernelDeimos]

This is too out of date to merge so I added @howardroark as a co-author of my commit to preserve contribution credit. Sorry on behalf of everyone that this was open for 9 years - it's getting better as we continue to knock down backlog