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.

https: Fix build after https://github.com/xenolf/lego/commit/0e26b

Fix up last-second changes

Fixes #640

Without -ldflags, the verison information needs to be updated manually,
which is never done between releases, so development builds appear
indiscernable from stable builds using `caddy -version`.

This is part of a set of changes intended to relieve the burden of
always updating version information manually and distributing binaries
that look stable but actually may not be.

A stable build is defined as one which is produced at a git tag with
a clean working directory (no uncommitted changes). A dev build is
anything else. With this build script, `caddy -version` will now reveal
whether it is a development build and, if so, the base version, the
latest commit, the date and time of build, and the names of files with
changes as well as how many changes were made.

The output of `caddy -version` for stable builds remains the same.

Based on work started in, and replaces, #614