feat(trace): Log output readability and consistency

[dnut]

The motivation of this change is to improve the readability of the logs without introducing a new formatter or breaking our existing compatibility with the logfmt standard.

Timestamp

Currently our log messages have the timestamp at the end of the line. This means the timestamp is in a different position for every log message, making it difficult to find when you're quickly skimming the logs.

This PR moves the timestamp to the beginning of the line. This is typically where loggers display the time, so it's what most people will be used to.

Putting fixed-size items at the beginning of the line improves the alignment of the log contents, which makes the logs more organized and consistent. This helps the logs look a little more like a table instead of randomly scattered text.

It's typical to look at the timestamp for multiple messages at once, to understand how long certain processes are taking. By keeping the timestamp in a consistent location, this process is easier.

Warn

I also changed "warning" messages to be printed as "warn". This also has multiple benefits:

• Consistency between the code and logs: Previously the code said "warn" and the logs said "warning". Now both say "warn"
• Consistency with other logging libraries: "Warn" is more commonly used as a log level than "warning" in most other languages. The standard loggers in Zig, Rust, Go, and Java all use the word "warn."
• Log alignment. Similar to the point for the timestamp, "warn" helps improve the alignment and visual appearance of the logs. With 4 characters, it's closer in length to other log levels.

Refactor

I refactored the writeLog and countLog functions to extract out the common logic into a single function. This makes it easier to keep the two functions consistent with each other.

Other ideas

I was also tempted to pad out the log-level with spaces to ensure that it always uses the a consistent number of characters, thus perfectly aligning the next field (scope). All log levels are 4 or 5 characters, so this would mean adding an extra space whenever the log level is 4 characters. I didn't implement this because I'm not sure if it deviates from the logfmt standard. Probably not, but I'm playing it safe since it's not a huge benefit either.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Files with missing lines	Coverage Δ
src/trace/level.zig	100.00% <ø> (ø)
src/trace/log.zig	87.13% <100.00%> (ø)
src/trace/logfmt.zig	96.55% <100.00%> (+3.21%)	⬆️

... and 2 files with indirect coverage changes