@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)
If the benefit of HAL is simply using names over URLs then it seems like a tiny benefit at the cost of extra HTTP requests and the overhead of a HAL client library (and the cruft it brings with it like url caching logic—which btw seems to defeat the point of being able to update URLs underneath at anytime).

I'd argue names over urls are just an unnecessary level of indirection. So you use `api.artist(id: 123)` over `get('/api/artist/123')`... seems like you essentially just replaced slashes with dots. Again, I hardly remember a time when URLs changing were a problem—and when they rarely do—search + replace and I'm good for another several months. Also lets not forget HAL still breaks when we say rename `exhibitions` -> `fairs` only in a non-HAL API we could redirect `/api/fairs` -> `/api/exhibitions`, but in HAL we just broke a client because of that extra level of indirection e.g. `_links: { exhibitions: }` becomes `_links: { fairs: }` and our crawler errors `Could not find a link nor an embedded object for "fairs"`.

I'm not seeing what's wrong with that ObjC code. Looks like a reasonable list of endpoints and request objects. If it's the extra boilerplate code that's a problem you could also have just dropped straight `[staticHTTPClient requestWithMethod:@"GET" path:@"/api/v1/me" parameters:nil]` in your app code and avoided those files all-together. There's probably a good reason for doing it that way though, and I can see how HAL avoided the constants in the first file, but not seeing how it replaces the ARRouter code any better than just choosing not to write wrapper methods for `[staticHTTPClient...]`.

But my quest for HAL enlightenment goes on in Positron and I'll let you know if my opinion sways ;)