@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)
The whole point of HAL is that you manipulate objects, not make HTTP requests. 99% of your example above is boilerplate and should not be there at all. So it should be something like this:

``` javascript
api = new Api(url: 'https://api.artsy.net')
api.get ->
   artist = api.artist(id: '4d8b92b34eb68a1b2c0003f4')
   artist.get -> 
      artist.artworks.get ->
```

Because the API is self-describing it can derive all URLs from the above by "name", and you never need to worry about URLs, all these relationships are expressed by the API itself.

To answer your question, is `api.links.artist.expand(id: id).resource` better than `Net::HTTP.get`. Definitely yes, because in the latter there's zero domain logic, it's HTTP boilerplate. In the former (ignore `.links` and `.expand`) we're doing `api.artist(id: id)`, which is all Artsy domain and no "transport".