Be more aggressive when checking if a log message should be sent to the underlying logger

[leonardehrenfried]

sbt/sbt#3711 has shown that substantial amount of time is spent calculating log messages that are unlikely to be displayed.

This PR introduces checks that filter out log events for disabled log levels.

It does this on two levels of abstraction which may be redundant and is deserving of critical review. The reason for this is there is non-trivial message construction is happening in ManagedLogger but to me changing AbstractLogger would offer a more general solution for all types of loggers.

Lastly, I upgraded the versions of scala as well as the scalafmt plugin.

[dwijnand]

LGTM. Thank you @leonardehrenfried.

[eed3si9n]

This goes against the current design of sbt logging.
In sbt 1 the logger doesn't fully know whether something should be logged or not since that's determined by the appenders that subscribes to the logger. Making this change would break last command.

The log message produced by Ivy (sbt/sbt#3711) I think should be treated as special case since the integration of Ivy logging (via slf4j?) is something new to sbt 1.

[leonardehrenfried]

@eed3si9n Thanks for the review. Do you think that changing https://github.com/sbt/librarymanagement/blob/1.x/ivy/src/main/scala/sbt/internal/librarymanagement/IvyLogger.scala#L25 would be the way forward?

Or should sbt/util be changed and check the logger name to filter out ivy log events?

[leonardehrenfried]

Closed in favour of #132