Disable log level traits

[kukushechkin]

Add compile-time traits for eliminating log levels from binaries

Motivation:

Applications often know in advance which log levels will never be needed in production. For example, a production service might only need warning and above, while trace and debug levels are only useful during development. This PR introduces
compile-time traits that completely eliminate unwanted log levels from binaries, achieving zero runtime overhead for disabled log statements.

Modifications:

• Added seven MaxLogLevel* traits
• Extended benchmarks with the MaxLogLevelWarning suite
• Added "Disable log levels during compilation" section to the best practices guide

Result:

Users can eliminate unwanted log levels at compile time by specifying traits in their Package.swift dependency declaration.

[czechboy0]

Do we think anyone will want to eg only disable Info level, but keep all the other ones, including Debug/Trace? If not, I think a nicer spelling would be "DisableInfoAndLower", where we disable a specific level + all less severe ones.

// Edit: I think Rust got it right here by using these "max level" traits, I think we should do the same: https://docs.rs/log/latest/log/#compile-time-filters

[ktoso]

LGTM!

I was wondering if we need to prefix the traits with SwiftLog... but maybe not, this is "the" logging package after all...

I think the individual control over each level is good; users can always just put them all/most if they want, I think this is good enough rather than doing the many "at most..." versions and the specific versions etc. 👍

[kukushechkin]

Do we think anyone will want to eg only disable Info level, but keep all the other ones, including Debug/Trace? If not, I think a nicer spelling would be "DisableInfoAndLower", where we disable a specific level + all less severe ones.

// Edit: I think Rust got it right here by using these "max level" traits, I think we should do the same: https://docs.rs/log/latest/log/#compile-time-filters

I agree "max level" traits are a better user experience. My main concern is covering all the combination with tests (and separate benchmark targets is the only way to get a package with different traits) produces an enormous amount of prerecorded thresholds. So if we're fine not covering all the combinations with tests, then it should be fine. I'll prepare an update.