Use an external HTTP universal interface instead of rspotify-http

[marioortizmanero]

Is your feature request related to a problem? Please describe.

Ever since we abstracted away the HTTP clients into the BaseHttpClient trait I've wanted to consider making it a public crate outside of rspotify. The current rspotify-http should just be a dependency, and worked on externally. Separating the module into the rspotify-crate was the first step. Not only would we actually separate http logic from spotify's API, but also have support from the community and reduce the maintenance work needed for Rspotify.

This isn't really a top priority right now as it might be a bit complicated, but ideally it should be released before v0.11 in order to avoid confusion.

Describe the solution you'd like

I think the best way to handle the HTTP client abstraction would be to create a separate crate, as I can imagine it's a frequent problem for other API wrappers like us and we could do with some support from other developers outside of Rspotify. This way it'll be much easier to add new clients.

After investigating a bit I've found the following already-existing crates:

• fMeow/uclient, from the creator of maybe_async, just what we're looking for. Problems: (1) seems a bit abandoned currently, (2) uses maybe_async, so Avoiding conflicting features; allow multiple HTTP clients at once #221 remains unsolved. @fMeow, do you plan on maintaining the crate any further?
• http-client: "Types and traits for http clients", very similar and well maintained. Not sure if it's the exact same as uclient, I should try it out. Problems: I think it only supports asynchronous clients currently.

Other crates that implement HTTP interfaces with maybe-async:

• https://gitlab.com/qonfucius/aragog
• https://github.com/fMeow/arangors

[marioortizmanero]

We should probably do this after #221, since it may change the way Http clients work.

[github-actions]

Message to comment on stale issues. If none provided, will not mark issues stale