systemd unit file

Add systemd service file for caddy

Add some README with basic setup instructions

Explain how to view the service configuration

Add a note about permissions

Add a comment about run user and group

service->service unit

A systemd service can consist of different units. A unit configuration
file has the `.service` file ending which is a bit confusing, so please
be considerate if I'm confusing `service` and `unit` in the README

Fix typos/reword

Add contact information

markdown: Included files in Markdown templates have access to document vars

Refactor how middleware.Context includes files

mime: Use a map, and error on duplicate extensions.

 - The mime middleware used filepath where it should arguably use path.
 - Changed the configuration to use a map instead of scanning an array
   during every request.  The map is static (after configuration), so
   should be fine for concurrent access.
 - Catch duplicate extensions within a configuration and error out.
 - Add tests for new error case.

proxy: Add max_conns parameter for per-host maximum connections

Play nice when ACME used manually.

Add flag to list directives.

Folder for init scripts within dist / FreeBSD service script

Hide only the currently used Caddyfile

Minor change to server/server.go such that /.well-known/acme-challenge
can be passed through when TLS.Manual is true on the vhost the request
came in through.

capitalize struct name in comment (go lint)

# Conflicts:
#	middleware/fastcgi/fastcgi.go

That was weird, only half of the file got committed...

Added a directory dist/init/ that may provide service scripts for various distributions in the future, added a experimental FreeBSD service script

https: Support ECC keys

fastcgi's ServeHTTP method originally returned the correct value (0) in
b51e8bc1. Later, I mistakenly suggested
we change that to return the status code because I forgot that status
codes aren't logged by the return value. So fastcgi broke due in
3966936b due to my error.

We later had to try to make up for this with ugly Content-Length checks
like in c37ad7f6. Turns out that all we
had to do was fix the returned status here back to 0. The proxy
middleware behaves the same way, and returning 0 is correct. We should
only return a status code if the response has not been written, but with
upstream servers, we do write a response; they do not know about our
error handler.

Also clarifed this in the middleware.Handler documentation.