Add document name/segment utils

Various util functions for working with Documents are expected to go in
here.

As you can see, I already have the basic function for splitting Document
names (with validation), implemented and tested.
Switch to gocheck

I can find some good reasons to use an external testing library (less
boilerplate and custom assertion code, easier pretty printing). I chose
check because it's already on gopkg.in and I trust @niemeyer. It doesn't
need me to change the way I think about tests or write them, just gives
me some nice bonuses.
Add SegmentsToName

Validating form of strings.Join(), reverse of document.NameToSegments.
Invalidate "." or ".." segments in Document Names

I forgot about these two cases initially. I also had some test coverage
missing.

Future optimization for NameToSegments: do it all in one long pass,
rather than calling Index and HasSuffix over and over.
Add Document/DocumentStore

This is the key to Goose's storage API. It's one commit, but a lot of
thought went into the interface that's exposed here.
Add DocumentStore factory API
Add FileDocumentStore

The in-development implementation of DocumentStore. Having a starting
point will make it easier to write more tests and get a more robust
acceptance suite.
Implement /w wiki routes

Preparing for the implementation of rudimentary wiki functionality.
Have to say I don't really like how pathprefix works. The root path is
badly handled in this case. I might implement some hard-coded 301s for
those, or just... shrug and ignore them.

Also, I'm going to need pretty printed errors for 404s and 50xs soon.
Need to think about the structure of those.
Convert some PathErrors to DocumentNotFoundErrors

If the directory existed but was empty, a DocumentNotFoundError would be
returned (as expected). However, if the directory did not exist at all,
there would be an os.PathError for trying to open it. This error was
propagated back to the caller. Instead it should be identified, and then
replaced by a DocumentNotFoundError.

To catch this bug in the future, I put some more complete tests, but its
reproduction (at least for FileDocumentStore) is order-sensitive. If the
other tests run first, they'll create and then destroy the documents,
leaving the directory behind, which causes the empty-case to pass.
Refactor reading directories

Several issues with the way I was handling this before:
- first, there was actually a bug where directories would be counted
  in the list. This screws up all the iteration everywhere, so if you
  have documents /foo/bar and /foo/bar/baz, all the operations on
  /foo/bar will be broken. We need to exclude directories in all cases.
- second, we have to convert several cases of PathError to DNFError as
  resolved in some earlier commits. But we don't want to do that at all
  the call sites. Code repetition!
- third, we don't want to act on a document directory that's empty. That
  is also a DNFError. And we had to repeat that check in several places
  too.

The refactor combines all the logic into a single function that gets
spammed everywhere else in the FileDocumentStore. Much better!
Refactor Get and GetAll file reading

Combine the file-to-document unmarshaling in Get and GetAll into another
function. There's some future refactoring between the two refactored
functions as well, for the PathError->DNFError conversion. We can do
that later.
Restructure FileDocumentStore godoc comment

Turns out godoc doesn't really like my bulleted-list style of comments.
Looks fine on the console, but it renders badly in HTML, because the
indented lines of a long bullet are interpreted as code blocks. Whoops.
Add test for multiple documents

This is a rudimentary test to prove that documents are isolated from one
another. This would have caught the bugs regarding ioutil.ReadDir, but I
refactored that bug out already.
Add wiki page retrieval

The application can now retrieve wiki pages from its DocumentStore and
show them if they exist. It's still plain text, but I'm really satisfied
to see that it actually works.
Provide template initialization

Go's template API can be a bit arcane at first glance, but it actually
provides a simple way to group a whole bunch of templates together and
let them reference each other. I found this to be helpful:
http://golang-examples.tumblr.com/post/87553422434/template-and-associated-templates