Use slf4j-api instead of depending on a concrete logging provider

[bestbeforetoday]

SLF4J is designed as a facade (or abstraction) for various logging concrete logging implementations (see SLF4J documentation for details). The SLF4J has this guidance for libraries:

Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding/provider but only depend on slf4j-api. When a library declares a transitive dependency on a specific binding, that binding is imposed on the end-user negating the purpose of SLF4J. Note that declaring a non-transitive dependency on a binding, for example for testing, does not affect the end-user.

Rather than depending on slf4j-api and allowing consumers to link to a concrete logging provider of their choice at deployment time, this project has an implementation dependency on slf4j-jdk14. I propose depending only on slf4j-api and documenting that consumers should add a dependency on their concrete logging provider of choice.

[bestbeforetoday]

I am happy to work on this if you agree with the approach.

[vbarua]

This seems perfectly reasonable to me. I'd be happy to review this change if you were to make it.

[bestbeforetoday]

Resolved by PR #244 and published in v0.31.0.