@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)
This has been an awesome discussion so far, I look forward to seeing this evolve!!

I too am kind of in @craigspaeth 's camp - and I think I also don't quite 'get' or fully understand the HAL spec. I do totally concede that the link and link-following behavior makes it more easier than conventional URL/route-based API's  (like our V1) for the following:
  - building a super-generic API client, just point at the root and follow links based on given inputs until you arrive somewhere
  - exploring the API, via literally clicking by hand in the browser and seeing different resources that are available, as well as crawling the API (similar to the above generic API client)

I think an advantage this spec has over our V1 is that the client really needs very little knowledge about our API URL structure, nested routes, etc. As an example, to currently retrieve all the artworks in a sale - one has to know to go to /sale/:id/sale_artworks , or first go to /sales and pick one, etc. That's actually pretty tightly coupling the client with the API structure, at that time. With a HAL API one can start at the root, and as long as there are 'sales' and 'artworks' links you can get your data, w/o having to know much else. And if we decide to totally change the data modeling internally we are free to do that, as long as we respect keeping those links active with the expected JSON payloads for different objects (with a separate deprecation strategy for changing responses).

That is **quite** powerful, and I suppose with a public API, and supporting many more clients, is a strong argument for it and something to consider. However, I totally agree with @craigspaeth that massive changes to API URL structure and nesting has not really happened that much, and has usually been fine to make the occasional change and update. What has been several orders of magnitude worse (IMO) in terms of bugs and time to fix, is the other changes that have happened - namely, fields being added/removed/renamed from JSON, payloads changing, caching issues, pagination/error/auth/other behavioral things, etc.

I think Hyperclient is awesome and being able to make clients like that is awesome, but most of us here are generally making client apps that are tightly coupled to the current API and current state of data modeling (by choice and necessity) and for that - I think HAL is more work/confusing than not. For the public it's better, but for internal client stuff like this it seems, at least now as I'm not super educated on it, trickier.