Isolate Requestor API from JQuery.

[dwaite]

A patch to make the interface for the Requestor types depend on a more constrained set of options, and to not require JQuery, while still aiming to maintain a runtime-compatible interface.

• Requestor takes a RequestorSettings rather than a JQueryAjaxSettings. This new interface is based on the subset of JQueryAjaxSettings used by AppAuth-JS internally.
• JQuery and test implementations moved out to jquery_requestor.ts and test_requestor.ts
• Requestor and RequestorSettings types moved to requestor.ts
• NodeRequestor refactored to rely on new interface
• xhr.ts changed to a backward-compatibility export of the Requestor, RequestorSettings, JQueryRequestor and TestRequestor types.
• index.ts changed to export new types directly
• RevokeTokenRequest and TokenRequestHandler refactored to pass a StringMap rather than building a URL-encoded form themselves.

[dwaite]

Note: I could also create a patch using something like lquixada/cross-fetch , but the comments made me think that fetch polyfill usage had been evaluated and rejected.

[dwaite]

Also I am curious about the reason why this change is being made. What was the original problem which you were trying to solve.

Rather than my code requiring jQuery, I implemented a fetch-based requestor. I still had to bring in jQuery (apparently I misunderstood the error and just needed the types at compile time - which makes more sense) and had to reverse engineer which parts of the very large jQuery.xhr API was actually used. Not having any contract for that subset of the API meant that my fetch-based requestor could break at any time.

Once I started fiddling with it, it seemed like something I could clean up and offer to contribute back.

[tikurahul]

The only dependency we have are on the typings and not jQuery itself.

I think we could consider re-purposing the types defined in what-wg fetch. Rather than define a subset, I think that might make things easier to reason about.

[dwaite]

Would a PR using whatwg-fetch be desirable? I wouldn't mind tinkering with that at all.

[tikurahul]

Yes. I think so. I think that is the API more developers are going to be familiar with going forward.

[dwaite]

Closing, replaced with #48