Fix #598: Allow external configuration of logStartupMessage via Properties and Env Vars

[oshai]

Addresses #598 by adding support for configuring KotlinLoggingConfiguration.logStartupMessage externally via System Properties and Environment Variables across all supported Kotlin Multiplatform platforms.

Currently, disabling the startup message programmatically can be awkward or impossible if top-level loggers initialize KotlinLogging during class loading before main() or test setups have a chance to run. Providing external configuration flags completely bypasses this initialization order constraint.

To maintain backward compatibility and avoid confusing users who rely on startup diagnostics, the default behavior remains true (opt-out).

Cross-Platform Implementation Details
The default value for logStartupMessage is now dynamically resolved during initialization based on the platform:

JVM & Android: Checks the JVM System Property kotlin-logging.logStartupMessage first, then falls back to the Environment Variable KOTLIN_LOGGING_STARTUP_MESSAGE.
Native & Darwin: Uses POSIX getenv to check the KOTLIN_LOGGING_STARTUP_MESSAGE environment variable.
JS & Wasm JS: Safely evaluates the Browser environment (window.KOTLIN_LOGGING_STARTUP_MESSAGE) or Node.js environment (process.env.KOTLIN_LOGGING_STARTUP_MESSAGE). Returns false if either resolves to "false" or boolean false.

Fixes #598

[mikehearn]

Looks good, but I would also vote for just deleting it. There have been logging libraries for decades and I never saw one with a startup message like this. It seems very unlikely anyone would be confused and no tools should be relying on it for backwards compatibility.

[Zordid]

When is this going to be released? I want to finally get this message disappear. I don't even know why you added this and defaulted it to appear... :-(

[Zordid]

Looks good, but I would also vote for just deleting it. There have been logging libraries for decades and I never saw one with a startup message like this. It seems very unlikely anyone would be confused and no tools should be relying on it for backwards compatibility.

Absolutely. It was added, but it hurts more than it adds. Everybody fights to get it off. Why was it added, what was the reasoning? When it was added lately, why wasn't backwards compatibility an issue? Why is it now for something so new, nobody can rely on it?

[oshai]

The log startup message was introduced with the following design rationale:

Prevent User Confusion & Assist Debugging: With the shift to a unified multiplatform Universal Provider Architecture, the active logging provider (e.g., SLF4J, OSLog, Direct) became dynamically configurable and could vary by platform. Printing the active loggerFactory helps developers immediately confirm their exact runtime setup.

This was introduced in #584.

I am working on finishing this PR and releasing it.

[oshai]

released in 8.0.03 (will be available soon).