Refactoring of logging

[phillebaba]

Describe what should be investigated or refactored

Test week proved that certain functions are difficult because logging logic is tightly coupled with other logic. For example there are a couple of functions which will print formatted tables to a global logger instead of returning structured data and allowing the caller to deal with the output. Additionally there are a couple of places where errors are logged and exit is called instead of returning errors and allowing the called deal with them. We have also discovered that Pterm is not thread safe as documented in #2558 which causes more issues for unit testing.

For these reasons it has become apparent that some sort of refactoring of logging is required. A lot has happened since the initial implementation, like structured logging in standard lib. We need to define what logging is specific to the CLI and what is logging which is useful for those importing Zarf as a CLI. While it may complicate things we have to decide whether or not spinners and other "UI" elements should be used in any exported packages.

Links to any relevant code

https://github.com/defenseunicorns/zarf/blob/0c02643b9f5631a7bdd98650cc87c74901190771/src/pkg/utils/wait.go#L53
https://github.com/defenseunicorns/zarf/blob/0c02643b9f5631a7bdd98650cc87c74901190771/src/pkg/packager/common.go#L132

Additional context

We should split the work into a couple of steps to avoid creating a mega PR.

Tasks

• Remove use of message fatal.
• Determine where and how spinner should be used.
• Define an interface that should be used for logging.
• Replace use of Debug, Warn and Info with structure logging
• Replace use of spinner

[phillebaba]

I realize that message fatal prints the debug stack when an error occurs which exits the program. Additionally some logs will differentiate between the message and the error. The error is only written to the debug logger which the message is written to the error writer.

Before removing this logic we need to determine if this is a feature required by end users.