@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)
Here's an example using traverson in coffeescript to get Andy Warhol:

````coffeescript
api = require('traverson').json.from('https://api.artsy.net/api')
api.newRequest()
  .follow('$._links.artist.href')
  .withRequestOptions(headers:
    'X-Xapp-Token': 'xapp_token'
    'Accept': 'application/vnd.artsy-v2+json'
  )
  .withTemplateParameters(
    id: '4d8b92b34eb68a1b2c0003f4'
  ).getResource (err, resource) ->
    console.log resource.name # Andy Warhol
````

I'm skeptical of the benefit of this over hard-coding urls. Before I dive in to a rant here I do want to say I definitely see the self-documenting benefit and I like how it's easy to click around links and see how to get related data.

However, it seems like a lot of overhead (and unnecessary HTTP requests) for the hypothetical win that maybe we can change urls down the line without breaking clients. In my experience urls changing were never a problem. The breaking changes that messed up my clients have been things like pagination limits changing, properties on a data model changing, inconsistent error json formats, or other data-level things. Doesn't seem like HAL has any standard for dealing with those kind of changes.

Also I don't see how

````ruby
api = Hyperclient.new('https://api.artsy.net/api').tap do |api|
  api.headers.update('X-Xapp-Token' => xapp_token)
end
api.links.artist.expand(id: '4d8b92b34eb68a1b2c0003f4').resource
````

is all that much nicer or more future-safe than

````ruby
Net::HTTP.get(
  "https://api.artsy.net/api/artist/4d8b92b34eb68a1b2c0003f4?access_token=#{xapp_token}"
)
```

Seems like you've avoided the dependency of a url with `/api/artist/:id` in favor of a dependency on `_links: { aritst: '' }` being returned.

Maybe I'm just not seeing the big picture though. Do you know of any blog posts or othwerwise that are an example of how HAL was an awesome choice for clients and allowed an API to evolve underneath a client app without breaking it? Or maybe I'm totally missing the point of HAL and it's not about flexible urls/non-breakin apis, but some other benefit?

I don't want to be a wet blanket on the HAL party I'm just finding it hard to justify writing a Traverson + Backbone library that does all of this traversal stuff when I could much more easily just use Backbone the vanilla way and deal with urls changing down the line once and a while. It's also possible Backbone is not the tool to really take advantage of HAL and to really feel the wins there needs to be a model library written around HAL.

Curious on others thoughts about how one would go about using Backbone The HAL Way™. As for integrating with Spooky I can be convinced to do it the HAL way, but right now it seems a lot simpler to keep the hard-coded urls.