Consider decoupling service from console functions

[jeroenheijmans]

The oauth-service.ts file has many console.error and console.warn calls. This is possibly great default behavior, but I'd like to be able to overwrite it for two main reasons:

1. Sometimes I disagree with the error. Put differently, I'm working on a case currently where the console.error is not an error but an expected exceptional situation which I will handle myself.
2. In production I'd prefer to keep my console clean of anything but critical stuff, and have a logging service to catch all the other stuff

For those reasons I propose we decouple the OAuthService from console functions, for example similar to how you can inject a different OAuthStorage.

Some (pseudo)code:

export interface OAuthLoggingAdapter {
  warn(message?: any, ...optionalParams: any[]): void;
  error(message?: any, ...optionalParams: any[]): void;
}

and default:

{ provide: OAuthLoggingAdapter, useValue: console },

then the service can rely on OAuthLoggingAdapter being injected (replacing all console.warn/.error calls), and users of the library can themselves provide a different implementation, if they like.

I'm happy to write a PR for this, but before I do so I'd love to get some feedback on whether it's a good idea and whether the PR has a chance of being accepted.

[manfredsteyer]

Great idea. Care for a PR? I'm preparing a new version soon.

[jeroenheijmans]

I've created PR #427 for this, trying to stick closely to the conventions set in the library, taking OAuthStorage's implementation as an example.