Logging

Problem/Motivation

The client should be capable of using a custom logger. 🪵

Proposed resolution

* A 'logger' property should be added to the base ApiClient class.
** Logger will be an object optionally containing methods for each of the NPM logging levels: error, warn, info, http, verbose, debug, silly.
* A 'log' method will be added to the base ApiClient class.
** log will take a level and a message (both strings) as parameters and call the equivalent logger method (passing the message) if it exists.
* A defaultLogger utility will be added to the ApiClient package.
** It is a logger that uses console.log/debug/warn, etc. for the related logging levels.
* The ApiClient class will use the defaultLogger if a custom logger is not provided.
* A debug property will be added to the JsonApiClient class.
* If debug is true, the client will perform debug logging using the provided logger.

Remaining tasks

* Implement changes as outlined above.
* Document inline using tsdoc
* Add test coverage.

Determine which (if any) logging library to use as a default logger.
Some libraries include tslog and typescript-logging
- Current example just uses a zero dependency solution of console log methods. Wondering if maybe this is the right choice for the base class, and we could later decide to use a logging library for the JsonApiClient if we prefer it.

How verbose will the logs be? Should we allow multiple levels of verbosity?
- Current example uses a debug logging level when debug is enabled. The logger following npm logging levels adds some flexibility here.

Should we provide a way to pass a variable to the logger?

API changes

* Adding a log method to ApiClient

Data model changes

ApiClient:
* Adding a logger property
* Adding a log method.
JsonApiClient:
* Adding a debug property