Sensible naming scheme for logging classes

Seeing as:

• The LoggerCallback-based classes (e.g. FileLogger) have “Logger”, not “Callback” in their name.
• Referring to the LoggerCallbacks as LoggerCallbacks feels ungainly and seems confusing, because it’s focusing on how they work instead of what they’re used for.
• Most documentation and instructional material refers to LoggerCallbacks as “Loggers”, which overloads the term.
• Trainer has a loggers hparam that takes a list of LoggerCallbacks, not Loggerss.
• We renamed LoggerBackend to LoggerCallback, but the Logger class still uses backend/backends as a parameter and attribute name.

I propose that we come up with a more sensible naming scheme. I’m not super opinionated, but I have a few ideas. Perhaps we change Logger to LogRouter, LoggingController, or LoggingFrontend. Thoughts @hanlint, @ravi-mosaicml, @siriuslee

[hanlint]

I’m of the strong held opinion that we should not rename Logger. It’s really the main user-facing API. The fact that we have these different destinations is an implementation detail, and the naming should reflect that.

If we accept that as a constraint, I’m not sure of any good options to handle this.

[ravi-mosaicml]

Discussed offline with @growlix; will rename LoggerCallback to LoggerDestination.

The rational was that LoggerCallback emphasizes the implementation (that it’s a callback) over what it actually does (that it’s where logging calls are sent). LoggerBackend was also considered, but backend isn’t as clear as destination.