Separate Superagent transport into optional module

[kadamwhite]

The core of WPAPI is the query builder: this can be used with any HTTP library, or with native XHR or fetch. It seems odd therefore that we require superagent no matter how you intend to use the library.

This WIP / Experimental PR creates a new module you can use via require( 'wpapi/superagent' ), to pull in the WPAPI object configured with a Superagent-specific http transport object. This is a breaking change, because it means that by default require( 'wpapi' ) will yield an object incapable of making HTTP requests; but it sets us up for a lot of flexibility down the road.

Input welcome on this proposal, and more to follow after the holidays!

Open questions:

• Do we continue to include superagent as a dependency, or make it a peerDependency or drop it as a dependency altogether, instead instructing users they must install it if they wish to require wpapi/superagent?
• Should this be wpapi/superagent (part of this repo), or a separate npm package wpapi-superagent? If the latter, it clarifies the dependency question somewhat.
• Should we include transport options using Axios and Fetch in the core package, as well?
• What gotcha's or issues might I be missing?

[kadamwhite]

This branch can now be tested with npm install --save wpapi@alpha

[kadamwhite]

@Shelob9 Fancy a quick code review? If I can get one pair of 👀 then we can land this and I'll move on to implementing the fetch and axios transports, then squash some bugs and get v2 out the door.

[Shelob9]

I just read the changes on my phone, looks good. I'll try to make time to test tomorrow.

[kadamwhite]

@Shelob9 🙌 Thanks much! I appreciate the initial review. To keep things moving I'm going to merge this now, but if and when you see any issues in testing, please open them as separate tickets, and I'll prioritize!