@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)
Alrighty solid points. I get that you're saying HAL allows using names like "artist" over urls, but what's the big advantage of that?

Sure, you're manipulating objects but those methods are still making HTTP requests. Doing `api.links.artist.expand(id: id).resource` is still going to make two HTTP requests to root and artist endpoints vs. hardcoding the url for one HTTP request to the artist endpoint.

Agreed the Traverson example is ugly b/c it involves some headers/etc. boilerplate. I was just making note of a working example with Traverson, not making a point about ugly HAL code.

However, now that you bring it up, I can see how HAL could make an API client library look elegant, but it doesn't seem to do much when you have to wrap that data in a model anyways.

So expanding on your example... With HAL this vanilla Backbone:

````coffeescript
new Artist(id: '4d8b92b34eb68a1b2c0003f4').fetch success: (artist) ->
  artist.fetchArtworks success: (artworks) ->
    console.log(artist, artworks)
````

becomes something like this:

````coffeescript
api.get ->
   api.artist(id: '4d8b92b34eb68a1b2c0003f4').get (artist) ->
      artist.artworks.get (artworks) ->
        artist = new Artist(artist)
        artworks = new Artworks(artworks)
        console.log(artist, artworks)
````

Of course that's a convoluted example but it sorta shows that while HAL lets you not hardcode urls it doesn't seem to gain much in the elegance factor.

Why is `api.artist(id: 123)` definitely better than `Net::HTTP.get...`? If the argument is the former is more elegant/expressive than I'd point to the example above where we need to wrap it in a model anyways e.g. `artist = Artist.new(api.artist(id: 123))` vs. `artist = Artist.find(123)`. If the argument is in the former you don't have to hard-code urls than I'd point to my earlier skepticism about changing urls actually being a problem and changing "artist" to "creator" still breaking both APIs.

I'm not denouncing HAL. I like that it's lightweight, I think there are good ideas behind it, and I'm happy to use Backbone with a HAL API. I'm just not convinced writing a Backbone + JS HAL library to traverse urls the-HAL-way in hopes that it'll hypothetically save me from breaking API changes is better than hard coding urls and updating them once in a blue moon.

I might be the only one who feels this way though, so if we're really set on all clients not hard-coding urls then I'm happy to figure out solution and update the PR.