@dzucconi (cc @dylanfareed): Initial wire up to Spooky

This starts to wire up Positron to Spooky. I've copy & pasted a lot of code from your [Force PR](https://github.com/artsy/force/pull/1272), so thanks for that.

I don't think I know enough about HAL yet to understand how to take advantage of it. Right now it seems like we're just going through the extra effort to override parse to ignore the `_links` and such. Maybe there's a way to write an adapter that better takes advantage of the automatic-crawling/not-hardcoded-urls ideas of HAL. Lemme know if you have any thoughts.

As a side note I've briefly looked at these which may be of use:
https://github.com/mikekelly/backbone.hal
https://github.com/basti1302/traverson
https://github.com/weluse/hyperagent

Still TODO: Write tests for the article/section models, which I will try to loop into my next PR.

![image](https://cloud.githubusercontent.com/assets/555859/4311152/6d0e3042-3eac-11e4-986c-029834e37a2a.png)
Ok, so you're saying that separation of concerns (retrieval over HTTP vs. domain model) is not a big advantage. I agree, it's cleaner, but it's not really that big of an advantage.

The small item above, retrieval of the root of the API, is really a small deal. It's something an app does once. Then it's "aware" of all root endpoints. You can cache that for a very long time.

Lets talk about URLs.

* The first is being able to evolve the API server-side. As long as link names continue existing you don't need to change client code. This doesn't have to be anything radical. For example, lets say we have changed artworks from one artist to many artists. We can preserve a link called "artist", that redirects to the first artist, and we can add a link called artists that returns the collection. No clients need to change. Another example is when parameters change. Lets say we want to default sorting to `-sortable_id` that was just added to artists - we can just add it to artists links and voila, all clients sort by that.

* The idea that 1 URL = 1 resource can be very powerful. You can have an artists link go to a list sorted by `sortable_id` in one case and `updated_at` elsewhere. The links can be called "artists" and "recently_updated_artists". On the client you never have to worry about implementation details and these two become API concepts, server-side.

* URI templates like curies allow you generally format URLs. The URL template rendering code should not live in the domain model IMO. Right now we're in the middle of changing how image URLs work. This would have been a breeze with a HAL format, we would just change it and all clients would continue work. 

I think you should build what you think is best. If you hard-code URLs, do it, but at least try to follow the idea of "less code" = "better" and move common retrieval logic further away from the models.