Implement new Atom API

[chrisgraham]

Q	A
Fixed Issues?
Patch: Bug Fix?
Major: Breaking Change?	No
Minor: New Feature?	Yes

This is a major expansion of Hybridauth, to be able to do two-way transfer of content data using a data structure based on the Atom feed format. This includes multimedia.

It fixes a major pain point many of us will have working with social media - while the companies give us APIs, they don't follow basic standards for interoperability as they are fundamentally disinterested (i.e. it's against their interests). With this, Hybridauth becomes middleware to provide this missing functionality.

You can even ask Hybridauth to create an actual Atom feed for you with this API.

It is up to individual providers to implement the API, if they can and want to. I've tried to avoid making this bloated, while also making it very flexible.

This initial implementation adds read/write support for Facebook, Twitter, and YouTube. It adds read-support for Instagram (as write-support is not possible in the public API).
YouTube is a totally new provider.

I expect this can all eventually replace the old status API that a few providers currently implement, as this provides all that functionality and a lot more. However, we don't need to worry about that for now.

Btw, some of the HTTP stuff is done using native PHP URL wrappers. This is because I didn't want to try and force the existing HttpClientInterface to deal with the unusual call patterns chunked uploading requires, and we can always rely on PHP URL wrappers working. If this is a problem (and I'm really hoping it's not), we should probably just rip out HttpClientInterface from Hybridauth and directly depend on Guzzle (if even that could do this cleanly, I don't know).

[chrisgraham]

It's almost a year since I wrote this, and I got no feedback :(. My hope with this patch was to align the interests of Hybridauth with development of CMSs which would want to provide content integration with social networks, a big time sink due to the multiplicity between the number of social networks out there and the number of CMSs. And something that aligns cleanly with the need to login to those same social networks, which already involves providing an abstraction around the networks' APIs.

Do people have any thoughts at all? Am I making Hybridauth too bloated, does this need to be in a separate library that somehow binds to Hybridauth? Does Hybridauth need to be forked into a bigger project? To me it is serving some important use cases a lot of people would come up with, and wouldn't make Hybridauth much bigger if the dated status APIs were removed from Hybridauth in response.

[RiverVanRain]

@chrisgraham Thanks for this PR. I'll try it on the holidays.