startup/shutdown: test file

Also modified NewTestController to include a value for OncePerServerBlock

wrote startupshutdown tests and added OncePerServerBlock value in the NewTestController function of the controller.go file

Fix for issues #297 and #298

Add option to change delims in templates

markdown, templates: Add Last-Modified header

Fix windows command parsing

Two quotes next to each other result in one escaped quote; Add Split Example, add/refactor tests for every platform.

We're not trying to test the shlex library; just our wrapper function

These tests with the backslash seem to assert that shlex (our Unix shell parsing library) is working properly, not our wrapper function (that parses commands for both Windows and non-Windows). These tests break on Windows so I have removed them.

Stinkin' backslashes

core: fileServer tests

Add TestNewDefault to config tests

Very simple test to make sure that NewDefault is populating the correct
fields with the correct values.

Test app.SetCPU, config.makeOnces, config.makeStorages

Also added ServerBlockHostIndex

This way, Setup functions have access to the list of hosts that share the server block, and also, if needed for some reason, the index of the server block in the input

startup and shutdown commands should only be executed once per appearance in the Caddyfile (naturally meaning once per server block).

Notice that we support multiple occurrences of startup and shutdown in the same server block by building the callback array incrementally as we parse the Caddyfile, then we append all the callbacks all at once. Quite literally, the OncePerServerBlock function executes only once per server block!

If each server block had only one sync.Once then all directives would refer to it and only the first directive would be able to use it! So this commit changes it to a map of sync.Once instances, keyed by directive. So by creating a new map for every server block, each directive in that block can get its own sync.Once which is exactly what is needed. They won't step on each other this way.

Turns out having each server block share a single server.Config during initialization when the Setup functions are being called was a bad idea. Sure, startup and shutdown functions were only executed once, but they had no idea what their hostname or port was. So here we revert to the old way of doing things where Setup may be called multiple times per server block (once per host associated with the block, to be precise), but the Setup functions now know their host and port since the config belongs to exactly one virtualHost. To have something happen just once per server block, use OncePerServerBlock, a new function available on each Controller.

Cover the rest of the (not one-liner) functions in context