Introduce logging abstraction

[kubukoz]

In #345, potential changes to the way we do logging were mentioned, among others a Logger[F[_]] algebra.

To be considered:

• defining our own algebra and interop modules for the most popular logging libraries (log4cats, odin, ???)?
• depends on typelevel/cats-effect#1479: using a cats-effect-std interface
• a default instance (noop? println?)

[Paulymorph]

Do you consider separate logging wrappers over a Cache[F[_], V]? (Like it is done in sttp as a reference)
Like

class LoggingCache[F[_]: <Bounds>, V](underlying: Cache[F, V]) extends Cache[F, V] {
 // implement all the methods with logging
}

As I see it:
There won't be major changes in the Cache interface.
Caching logic is separated from logic.
The idea is rather straightforward and users will be able to produce their own logging wrappers.
Logging for independent integrations like slf4j or log4cats can be implemented in separate modules.
This adds some responsibility on the library users as they have to wrap the caches in logger wrappers manually.