Write docs and test for listing overheards as json

I've decided to expose the `overheards` as a list of overheards; sorted
by recency.

Our test:

1. Creates a new overheard
2. Requests page at  `/` via GET as JSON
3. Asserts we got back JSON and that it was OK
4. Asserts the "zeroth" (i.e. the most recent) overheard was the one we
   just created

The documentation mirrors that. I'm only doing `curl` documentation for
this since it's likely people are familiar with their language of
choices libraries for sending GET HTTP requests.
Overheards may be listed as JSON

A relatively tiny change to the `get "/"` route allows us to expose a
json representation of our overheards! Hooray!

It also looks like we're getting some duplication; especially with our
`if request.accept?("whatever")` and `JSON.dump` bits.

This is an indication we could do some refactoring!

Why I changed the tests:
------------------------
* Again I misused `rack-test`. If you want to send headers, apparently
  you have to give it a body, even if it's a GET request! Ah well.
* `assert_equal` provides better output on failure than just `assert`.
Extract `render_json` method

This is similar to the `erb` method that we use to render HTML; however
it takes a hash of data to render as JSON in the response body instead
of a symbol representing a file in `views/`.

It gets rid of the `content_type "application/json"` and the `JSON.dump`
duplication; which makes our routes a little bit more human readable
Force ordering by created at

Sometimes my listing as jsonstest would fail for no obvious reason.
Turns out DataMappers `all` method doesn't enforce ordering by default.

We're telling data mapper to order results by the `created_at` field of
the `Overheard` model; and to put the largest (i.e. most recent) at the
top. [Documentation](http://datamapper.org/docs/find.html) (Search for
"Specify the order")
Extract `requesting?` helper

This provides a tiny bit of syntactic sugar that makes our routes look
even more like human speak (hopefully!)

Syntactic sugar is when we make a change primarily for aesthetic
purposes. It's not a bad thing, but it's not something I recommend
optimizing for.
Ordering by created_at date is fraught with peril

Hah. Well, figured out why the random test failure was occuring.

Our tests are executed so quickly that we frequently create both of the
overheards at the exact same second!

I debugged this by:

1. Explicitely creating *two* overheards in the test for retrieving a
   list by json.
2. Asserting that the first overheard in the response is the second
   overheard created.
3. `p` ing out the json that was being outputted and visually inspecting
   the datetimes
4. [Facepalming](http://media.giphy.com/media/siFaJVXkUiJHO/giphy.gif)
Merge pull request #10 from codeunion/4-expose-all-overheards-with-json

4 expose all overheards with json