Avoid use of Commons Logging in LoggingCacheErrorHandler public API

[vpavic]

At present, creating LoggingCacheErrorHandler with custom logger requires use of Commons Logging API, as the appropriate constructor expects org.apache.commons.logging.Log instance. As Commons Logging is rarely the logging framework of choice in applications these days, interaction with its API might not be desirable.

This commit adds LoggingCacheErrorHandler constructor that accepts logger name and thus avoids leaking out any details about the underlying logging framework, while also deprecating the existing constructor that accepts org.apache.commons.logging.Log.

---

I'm opening this PR to discuss one aspect of #28648 that was overlooked as that PR was superseded:

The first commit could maybe be update to deprecate the existing constructor that takes org.apache.commons.logging.Log and replace it with the one that takes String representing logger name as that way Commons Logging dependency wouldn't leak out at all. But I'd leave that decision to whoever reviews this PR.

These days, it's almost inevitable to have several logging frameworks on the classpath, with only one of those being the intended application-wide logging API. To avoid unintended use of other logging APIs, something like Checkstyle can be used to prohibit imports of undesirable classes. However, LoggingCacheErrorHandler makes this a bit difficult at the moment hence this proposal.

If you agree this proposal and also with the deprecation of constructor that uses org.apache.commons.logging.Log, I'll rework the tests to avoid use of deprecated constructor.