@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)
More solid points. I think regardless it would be helpful to experiment with a real client-app using a HAL API and Positron is a good sandbox to do that in. So, I concede and will give doing things the HAL way a try—hopefully writing a neat open source lib to make it easy to integrate this in the future.

To continue the friendly debate:

I do think the separation of HTTP retrieval and domain models can be important. It reminds me of DataMapper vs ActiveRecord, and while I do think there's value in separating retrieval/domain we've been using ActiveRecord in Rails for a while with little complaint. Regardless, Backbone does this to an extent by default via Backbone.sync vs. Backbone.Model.

I'm not arguing the value of separating retrieval to domain, I'm saying hardcoding urls is not a big deal. You could hard code your urls in a big config hash and pass them into `@model.fetch` or store them in DataMapper libs if you really wanted to keep _all_ HTTP related code out of models and it'd be the same debate of HAL crawling links vs. direct ping via hard-coded urls.

Yes it's small to retrieve a root API and cache it's response for future root requests. However something rubs me the wrong way about requiring clients to adopt a HAL client library that does smart caching just to start to use the API. From what I understand JSON+HTTP was a win over things like SOAP b/c it was simple and there wasn't necessarily a need for new client libs to interpret the response. Seems like requiring clients to use HAL in this crawling way is going backwards in that regard.

About URLS:

* To the artist->artists example—isn't that the equivalent of keeping an `artist` or `artist_id` key that points to the first artist alongside the `artists`/`aritst_ids` key? I also don't see how a client doesn't need to change... if I have `h1= artwork.artist.name` then I'm going to need to update it to `h1= artwork.artists.map(&:name).join(', ')` in my client at some point. The client could continue to work supporting a single artist from `artists.first`, but as explained earlier that can be supported with or without following links HAL-style.    
To the default sorting example: we could also redirect `/api/artists` to `/api/artists?sort=-sortable_id` to achieve this without HAL link-following. Also this seems like an example in which we introduced a breaking API change to a client e.g. the client expected the artists to be default sorted by name, we change it to iconicity, they automatically follow the new link and now we've broken their A-Z UI.

* I can see the hypothetical appeal to this, but sounds like you've just traded `/api/artists` & `/api/artists?sort=updated_at` for labels `artists` and `recently_updated_artists` instead. I don't understand what you mean about not worrying about implementation details. Unless you're saying a url is an implementation detail in which it seems to me to be just a resource locator like the HAL labels are. Although maybe I'm not stretching my imagination far enough on this one. The idea that 1 URL = 1 resource seems to be prevalent in both—that seems to apply to HTTP APIs in general.

* Agreed about url rendering code not living in the domain model. This seems to be a good argument for a HAL feature. However given the image urls example—why are we even asking clients to "render" urls in the first place?    
````
image_url: "http://artsy.net/iamges/123/:version.jpg
image_versions: ["small", "medium"]
````    
seems like a poor design choice when we could have just done the url rendering work for them 
````
images: [{
  id: 123,
  urls: {
    small: "http://artsy.net/iamges/123/small.jpg",
    medium: "http://artsy.net/iamges/123/medium.jpg"
  }
}]
````

In general I agree with the sentiments of separating retrieval/domain, less code = better & explorable APIs—it's the automatic url crawling I'm having a hard time getting on board with. Regardless I hope trying out things the HAL-way will enlighten things, and if not it'll at-least be a fun experiment.