feat(logging): Migrate to Go structured logging with slog

[Princess0407]

Description

urunc currently uses standard Go logging (log package or fmt.Printf) throughout the codebase. This produces unstructured, plain-text logs that are difficult to filter, query, or aggregate in production deployments.

Go 1.21 introduced log/slog, the standard structured logging package. Migrating to slog would enable leveled logging (Debug, Info, Warn, Error), structured key-value pairs, and JSON output.... all without external dependencies.

Proposed Work

1. Introduce a centralized logger in pkg/ or internal/ using log/slog.
2. Replace log.Printf / fmt.Printf logging calls with slog.Info, slog.Debug, slog.Error across:
   • pkg/unikontainers/ (VM lifecycle, network, initrd)
   • pkg/containerd-shim/ (shim operations)
   • cmd/urunc/ (CLI commands)
3. Add a --log-format flag to urunc CLI supporting text (default) and json.
4. Add a --log-level flag supporting debug, info, warn, error.

Why This Matters

• Structured logs enable filtering and aggregation in production (e.g., "show all ERROR logs from network setup").
• JSON output integrates with log aggregation systems (ELK, Loki, CloudWatch).
• Aligns with modern Go practices (runc, containerd both use structured logging).
• Zero external dependencies slog is in the standard library.

Acceptance Criteria

• slog logger is initialized at program startup with configurable level/format.
• All existing log calls migrated to structured equivalents.
• urunc --log-level=debug --log-format=json produces valid JSON logs.
• No functional behavior changes purely logging migration.

Non-Priorities

• Adding new logging frameworks (zap, zerolog, etc.)slog only.
• Changing error handling logic.
• Adding new features beyond logging.

I can start with pkg/unikontainers/ and then move on from there...

[cmainas]

Hello @Princess0407

I do not really see the purpose of this issue. This is a decision that maintainers should take. If you have a specific use case where the current log system does not help you, we will be happy to talk about that. However, random changes of logging do not really make sense.

[Princess0407]

Hiii@cmainas
The primary value isn't running e2e tests in Codespaces it's eliminating the manual setup burden for new contributors who want to run make unittest or make lint. Right now the installation guide requires: Docker, QEMU, Firecracker, Solo5, Cloud-Hypervisor, containerd, CNI plugins, devmapper setup, and Go toolchain. That's hours of work before a new contributor can run a single test. The dev container automates those exact steps. For e2e tests that need KVM, the local VS Code + Docker path handles that via --device=/dev/kvm. Codespaces handles everything....given the active LFX mentorships, this would let mentees get productive immediately rather than spending their first week on environment setup. Happy to scope it to just the Dockerfile and local VS Code support if Codespaces is a concern.