New handlers for FetchService

[lbwexler]

This provides support I need for being able to catch 401s, in non-SSO based scenario, and respond appropriately by bringing up.

The handler for the successful response seemed like a good thing to add at the same time for symmetry, and we have seen a couple of places where it might have been useful, and avoided the need for overriding FetchService to look for e.g. 200 returns with success: false

Hoist P/R Checklist

Pull request authors: Review and check off the below. Items that do not apply can also be
checked off to indicate they have been considered. If unclear if a step is relevant, please leave
unchecked and note in comments.

• Caught up with develop branch as of last change.
• Added CHANGELOG entry, or determined not required.
• [X ] Reviewed for breaking changes, added breaking-change label + CHANGELOG if so.
• Updated doc comments / prop-types, or determined not required.
• Reviewed and tested on Mobile, or determined not required.
• Created Toolbox branch / PR, or determined not required.

If your change is still a WIP, please use the "Create draft pull request" option in the split
button below to indicate it is not ready yet for a final review.

Pull request reviewers: when merging this P/R, please consider using a squash commit to
collapse multiple intermediate commits into a single commit representing the overall feature
change. This helps keep the commit log clean and easy to scan across releases. PRs containing a
single commit should be rebased when possible.

[lbwexler]

@ghsolomon -- thanks again for taking a look, and your comments -- refactoring to try to take account of your comments, I realized that I have a problem with the onResolved side. In particular, for some requests, we will be resolving to a processed any and for others to a FetchResponse

[lbwexler]

ok @ghsolomon -- can you take another look? Simplified this to deal with just the exception case.
Also -- made some orthogonal refactors/cleanups while working through this code that I think we should take.

[ghsolomon]

Looks good to me. One other thought - since we're supporting multiple exception handlers and only allowing developers to append their own, should we move our built-in library handlers out of managedFetchAsync and put them in that array initially? Could be a nice way to demonstrate the pattern and simplify managedFetchAsync a bit.

I.e. private _exceptionHandlers: FetchExceptionHandler[] = [this.TIMEOUT_HANDLER, this.ABORTED_HANDLER, this.SERVER_UNAVAILABLE_HANDLER]