[WIP] Faraday

@jcwilk Another proof of concept...

I created a Faraday adapter using crystal lake. I'm not sure this is the best strategy for the longterm implementation, but it seems to work.
@linedotstar - this is inverted from what i was imagining, but may very well be a good approach not sure yet. The cool thing about Faraday is that if you use it as the "backend" of an http client, it becomes a mega-adapter for dozens (?) of http clients to be hidden behind it, so, if we made CrystalLake use faraday to make its connections, then we could mount the app directly onto faraday so it'd be like...

lumos_rails internal api consumer -> crystal_lake -> faraday -> rack -> ruby env hash -> lumos_rails api

or, by mounting a regular client like Net::HTTP it could be

consumer -> crystal_lake -> faraday -> Net::HTTP -> HTTP calls -> lumos_rails api

which is awarded for free by making faraday the backend, it's the same idea as omni-auth

So if we did that, then if we were to break out a piece of the app and move it to a separate server, we'd just have to switch the faraday adapter and keep using crystal_lake exactly the same.

What do you think about that rather than making crystal_lake a faraday adapter itself? the downside with that is that then we'd still need to write client code around faraday since all a faraday adapter does is give uh... pseduohttp access to the consumer, i guess you could say?

If we made crystal_lake the code surrounding Faraday instead, then we could make crystal_lake use hyperresource like this: https://github.com/lumoslabs/self_service_analytics/blob/angular_grape/spec/features/queries_api_spec.rb#L29-L34 (commented it out for now cause i needed to do something else for spec-specific reasons)

I'd love to hash through different permutations of this in a sitdown though, let me know when you have time.