Revert refactor to utils.Log[s] and Cluster.get_logs

[charlesbluca]

The refactor of utils.Log[s] and Cluster.get_logs in #4909 can lead to errors in downstream projects that use these functions. This PR restores the original behavior of these functions, while making some minor adjustments to achieve what was done in #4909 (styling conditional on log level, tighter spacing between log entries).

• Closes Logging update breakages #4940
• Tests added / passed
• Passes black distributed / flake8 distributed / isort distributed

[jrbourbeau]

Thanks @charlesbluca! To make sure we're informed when any user-facing structure changes for Cluster.get_logs(), can we add/update a few small tests to make sure:

• Cluster.get_logs() returns a dict of strs (probably updating distributed/deploy/tests/test_spec_cluster.py::test_logs)
• Log is a str subclass (probably updating distributed/tests/test_utils.py::test_logs)
• Logs is a dict subclass (probably updating distributed/tests/test_utils.py::test_logs)

[jrbourbeau]

To be clear, we can change the structure of our output logs in the future, but we should raise deprecation or future warnings to let users know about any changes ahead of time

[ian-r-rose]

Thanks for the quick fix @charlesbluca, this looks good to me.

We certainly can guard against interface changes with unit tests as @jrbourbeau suggests, but ultimately I'd like to see a stronger delineation between the public and private dask APIs, especially for things that are intended to be subclassed. That way it would be clearer which things are more/less dangerous to change. That's well outside the scope here though :)

[jrbourbeau]

Thanks for such a quick fix @charlesbluca! Will merge after CI finishes

[ian-r-rose]

Thanks @charlesbluca !