@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)
I can kinda see your point with more complex urls, but IMO it's still a pretty small win for the costs.

1. If the argument is for readability
`published_artworks` doesn't really make it _that_ much nicer—`api.artists(id: 123).published_artworks` vs. `api.get('/api/artworks').query(artist_id: 123, published: true)`. Seems like you replaced describing published artworks via query params `/artworks?published=true` with a slightly nicer to read label `published_artworks`. In non-HAL style I would probably have this as a method on the model anyways e.g. in a ruby app like Kinetic `Artist.find(123).published_artworks`. HAL seems to simply have decided this name for you—if I didn't like the label HAL gave me, I might still write a wrapper to suit my style `Artist.find(123).artworks(published: true)` defeating the readability win.

2. If the argument is for not hard-coding urls
I would point back to my previous points about hardly remembering having a problem with urls changing underneath me. Seems like HAL lets you not depend on the url structure, but instead you have to depend on HAL's link structure. If HAL changes it's labels—your client code breaks just like it would break if you changed the URL structure. Only in some cases you might actually be able to keep clients working with URL redirects—if a HAL link changes I don't see how you avoid that breakage... I guess you could support the old link `exhibitions` along-side the new link `fairs`—but that actually seems worse than redirecting old urls. The idea that not depending on URLs is going to somehow stop client app breakage, and allow an API to magically evolve underneath it, seems incredibly suspect to me.

For the ObjC code—forgive my ObjC n00bness—but it doesn't seem like you _have_ to add 2 methods every time. That seems like a level of indirection chosen in Eigen (or probably most iOS apps?). For instance couldn't you just drop

(excuse the potentially-offensive ObjC code here)
````ObjectiveC
NSURLRequest *request = [staticHTTPClient
  requestWithMethod:@"GET"
  path:[NSString stringWithFormat:@"/api/v1/artwork/%@", artworkID]
  parameters:nil];
````

on [this line](https://github.com/artsy/eigen/blob/9a6df03e446c9d7b62b7209ee8b4069aa318470b/Artsy/Classes/Networking/ArtsyAPI%2BArtworks.m#L15) and ignore the whole ARRouter abstraction.

Not saying that's a good idea, the constants + ARRouter is probably a decent pattern ObjC encourages. However HAL doesn't seem to _solve_ this boilerplate code. It seems that instead of using your own constants to label urls you're using HAL's labels and dropping ARRouter in favor of depending on the request object builder in the HAL client you use. Using the HAL client library directly in your Classes/Networking code doesn't seem to be much better than just dropping in `staticHTTPClient` directly.

Also while I do think a vast majority of the time less code = better—it's not a hard fast rule. I don't find that list of constants offensively bloating the codebase. The ARRouter code seems to mostly be translating wrapper methods into HTTP query params, headers, etc. The equivalent in a Rails codebase might be extracting your `Typhoeus::Request` calls [like this](https://github.com/artsy/kinetic/blob/3976f4ee7a122462f600d4e2fde63ff3fa6adc42/app/models/kinetic/partner.rb#L55) into a `/lib/router.rb` library that allows you to put `response = Router.new_partner_stats_request` in there instead. The choice to do that means writing more code, but in Eigen's case it's probably a good idea and ARRouter = more code = better than the less code option.