qemu-run does not pad the log level

[BenFordTytherington]

During trying out #910, I noticed that the decoded output contained extra spaces after the log level, e.g. "INFO Hello, World!" instead of "INFO Hello, World!". This seems to be added by defmt-print, as the implementation of qemu-run which decodes it straight away handles it correctly, producing only one space.

Command I ran was

qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -monitor none -semihosting-config enable=on,target=native -kernel ../target/thumbv7m-none-eabi/debug/log 

to produce frames, and then piped this into defmt-print -e ../target/thumbv7m-none-eabi/debug/log.
Also tried (with the same issue) writing to a file first and then cat that into defmt-print, modifying qemu-run (as suggested in #876) to output undecoded, and using a direct pipe as well as into a file first. I Think due to these tests that the issue is somewhere with defmt-print, rather than the frames being produced, or I would expect the same behaviour in qemu-run.

[jonathanpallant]

I believe log levels are always padded with spaces so they are always 5 characters long. Otherwise you'd get jagged text alignment on the messages themselves.

[Urhengulas]

Yes, that padding is intended in order to align the log messages. It's documented in https://defmt.ferrous-systems.com/custom-log-output#log-level---l: "The log level is padded to 5 characters by default, for alignment purposes."

We should eliminate the difference between qemu-run and defmt-print by adding the padding to qemu-run.