Added Logger.debugEnabled and also increase zinc debug level with --debug

[lefou]

Add a def debugEnabled: Boolean to Logger, to targets can decide whether to compute some expensive debugging output or not.

Added a def zincLogDebug: T[Boolean] target to ZincWorkerModule, which defaults to be true whenever T.ctx.log.debugEnabled returns true. Thus, we always will see Zinc debug output, when we run Mill with --debug flag.

I mainly added this, to easily reproduce and debug this issue:

• Incorrect zinc modified binary dependencies #1901

[lolgab]

I'm not following the motivations behind this PR. Also isn't it better to have a more generic logLevel so it can be used with Error, Info, etc.? Also, why does it need to be a target? Is it a way to invalidate the caches when you change log level?
Also, why do you need a target specific to zinc?

[lefou]

I'm not following the motivations behind this PR.

We want to make Zinc more verbose in case we need to understand what's going on.

Also isn't it better to have a more generic logLevel so it can be used with Error, Info, etc.?

We already print all log messages from Zinc up to level info, so only debug level is missing, but only needed sometimes. Providing the log level configuration implies, that we create an abstraction / interface for it in the API. Once we have it, it's still questionable why we want to reduce the log level, so the only real use is enablement of debug. So, I though, just providing a simple flag is easier.

Also, why does it need to be a target? Is it a way to invalidate the caches when you change log level? Also, why do you need a target specific to zinc?

Zinc is a configured worker in a shared external module. It is typically shared between all ScalaModule unless overridden in ScalaModule.zincWorker. As the log level needs to be specified at Zinc initialization time, we need to re-initialize it with any config change. Hence, I've choosen a target for this configuration, to let it invalidate the worker whenever the debug setting changes. This is especially required when Mill is used in client-server mode. The server may already have initialized a zinc worker but when the client requests another log level, we need to re-initialize the zinc worker. I think, I forgot to make it an input target, though. I'll update this PR.