Add timeout to reload on goose restart

This fixes sporadic connection timeouts where a go file gets changed,
gulp rebuilds the binary and issues a browsersync reload, but the binary
is a bit slow to start. Browsersync tries to proxy the binary but it's
not listening yet, so the reload times out.

I know using sleep for this type of problem is the nuclear option, but
this is really annoying in development and I just want the bug to go
away in as little code as possible.
Remove PathPrefix in routes

I think Gorilla's approach to subtree routing is fundamentally broken.
If you want to route to an arm of the path trie, you have to use
PathPrefix("/foo/"). This route captures "/foo/", but does not capture
"/foo", so it can't cooperate with Gorilla's StrictSlash. It also risks
entering undocumented behavior if you try to define a route for
Path("/foo") specifically. Conversely if you use PathPrefix("/foo"),
now you will also match "/food", so you have to add that to your
handler as a special case. What a mess.

Custom regular expressions, although inelegant in and of themselves,
will at least present the correct routing experience for the user. The
new routes will not match "/w" or "/w/" (which is correct since those
should redirect to the home page), and it will match both "/public" and
"/public/" (which is correct because those should both show the index of
the static files being served). Stay tuned for more refactors along this
line.

Soapbox: My preferred API for this would be r.Subtree("/public"), which
would match anything under "/public/.+". It would also be possible to
add an extra handler for r.Path("/public") to catch the root case. This
is also compatible with Gorilla's existing StrictSlash API. You can kind
of do this with subrouters, but you end up back at the same problem,
because the subrouter would need to use PathPrefix instead of the parent
router. Maybe I'm just being whiny about regexes, but if I wanted to
write custom routes all day, I wouldn't use a third-party mux in the
first place.
Re-enable trailing slash on wiki routes

Gorilla invokes path.Clean in its router already, but it puts trailing
slashes back in case they mattered to you. So I have to call path.Clean
a second time to remove those. (Side note: I wonder why StrictSlash
is implemented via special regex behavior, instead of just switching
the path.Clean trailing-slash on or off. I'm sure there's a reason.)
Refactor render branches into type switch

Given that the type of the error return is meaningful, it makes more
sense to write this as a type switch than as many type assertions.
Add form POST action

I've been testing the form locally to get an idea of whether this works
or not, and it seems to be doing what I expected. Hooray!
Refactor template partials (p1)

The {{yield}} mechanism that unrolled/render provides is nice, but it
suffers from the restrictions of Go's template language. Easier to just
include a partial template, than to have a layout that wraps around the
body template.
Refactor template partials (p2)

Since the <head> is now in its own template, it only contains one
variable (the page title). We can set that to be the context of the
template itself, and then simplify the context in the including
wikipage.tmpl as well.
Refactor template partials (p3)

Now the error pages (404 and 500) use the same structure as the actual
wiki pages. That means they have a real navbar and what not.

I know there's some problematic code repetition in the HTML structure,
but Go's templates don't make it easy to factor that out. The {{yield}}
provided by unrolled/render is a hack to work around that limitation,
and it's still difficult to use. Future refactorings may find a better
way to share the <nav class="nav"><div class="container"></div></nav>
across pages, but for now it'll have to do.
Split WikiController into two handlers

Instead of a controller implementing http.Handler, it can simply provide
a bunch of methods matching the http.HandlerFunc signature. This is a
bit more flexible in the event that some of those functions share pieces
of the controller logic... which will be useful shortly.
Implement edit form route

The edit form route breaks into roughly three parts:

Some tweaks to main.go to actually add the route. Also, we can remove
the piece of test code that inserts a new document at startup, since it
can be done by hand once the form is implemented.

The template to serve the form. It's very rudimentary right now. The
action for the form is the POST to /w/foo/bar that was added in an
earlier commit (but I am considering moving this to another route).

The controller function to render the form. The function has to actually
fetch the document from the store, to prepopulate the content of the
form if the document does already exist. Luckily, we can reuse all the
handling logic for the existing controller function. It just happens to
fill in the exact functionality that is needed.
Move form action to /e/foo/bar with 301

I encountered a UX problem with my POST to /w/foo/bar. The user edits a
wiki page and immediately lands on that wiki page, which is good. But if
they navigate to another page and then press backspace, the browser asks
them to resend their submitted form. That's bad (it double-submits the
update AND it's also annoying).

The simplest solution is to move the POST action somewhere else and, if
the POST succeeds, perform a 301 redirect back to the wiki page where
the user can see the fruit of their labor. If they press backspace after
navigating onward, they'll go back to the wiki page without being asked
to resend the form. Much better.

What's really nice about the controller structure is that I can keep
reusing the handleDocument function for all three views. The logic is
somehow the same in every single case (the Update would be skipped on
some routes), so the only difference between the three HandlerFuncs is
the views they implement in response to the logic's outcome. I'm very
pleased with how this code looks at the moment.

Conflicts:
	main.go