fix: honour legacy 'source' config key as alias for 'container-engine'

[ricardbejarano]

Summary

Closes #643.

Before the CLI refactor in #587 (v0.14), dive read the container engine from a viper key named source. Config files with source: podman worked correctly in v0.13.x.

After the refactor the struct field was wired up with the mapstructure tag container-engine, so the canonical config key became container-engine. The legacy source key is now silently ignored, breaking existing configs for users who upgrade from v0.13.x.

Root cause

In the old viper-based CLI, the --source flag was bound to the viper key source and the config file consumed that same key:

viper.BindPFlag("source", rootCmd.PersistentFlags().Lookup("source"))

After the refactor, the --source flag still exists (for backward CLI compatibility) but it is now bound via fangs to the struct field ContainerEngine which carries the mapstructure tag container-engine. Config files using the old source: key are therefore silently ignored.

Fix

Add an unexported LegacySource field with mapstructure:"source" so that viper still reads the old key. In PostLoad(), when container-engine is still at its default value and source was explicitly set, promote the legacy value and emit a single deprecation warning. If both keys are present, container-engine takes precedence.

This mirrors the pattern already used by CIRules for its legacy camelCase keys.

Testing

Added unit tests in cmd/dive/cli/internal/options/analysis_test.go covering:

• container-engine: podman (current key) resolves correctly
• default (container-engine: docker) resolves correctly
• scheme prefix on the image (e.g. docker://...) overrides the config value
• legacy source: podman resolves to podman engine with a deprecation warning
• when both keys are present, container-engine wins