Consider using SuppressedError when invoking a callback in error steps

[domfarolino]

The catch() and inspect() operators have internal observers whose error steps invoke a developer-supplied callback with the given error value they receive. If that callback throws an error, then we must invoke Subscriber's error() method with the error thrown from the callback instead of the original error they intended to surface. This clobbering of the original error is exactly what SuppressedError intends to alleviate (first mentioned in #174), so we should consider using it in those operators.

[Jamesernator]

So this probably shouldn't be done for .catch as it's reasonable that a catch may already be replacing/wrapping the given error with a new error.

I'm now mixed whether it's even worth doing for .inspect given that there is opportunity to react to the given error, though it does seem more reasonable there as an error thrown from .inspect is probably a mistake in most cases.

There is actually one place in .catch though where the error is swallowed, and that's if the return value of the callback fails to be converted to observable:

obs.catch((error) => {
    // We can't catch the error from Observable.from
    return null;
});

so it might be worth doing a SuppressedError here.