Improve workflow run output for clearer progress and troubleshooting

[d-lazenby]

Summary

The current workflow logs are accurate but sparse, which makes runs harder to understand at a glance. We should add structured, user-friendly progress output so maintainers can quickly answer:

1. What is being scanned?
2. What version/ref was found?
3. What changed?
4. Why was something skipped?

Problem

Today, successful runs mostly show per-file update lines and a final replacement count. This is functional, but it is difficult to follow the end-to-end flow during manual runs, first-time setup, or troubleshooting.

Desired output style

Add concise lifecycle logging with clear stages and per-module outcomes, for example:

• Discovering modules in terraform/...
• Found module: remote-state (github) current ref: abc1234
• Querying GitHub for latest release of your-org/terraform-gcs-remote-state...
• Resolved latest tag: v2.1.0 -> SHA: def5678
• Module remote-state updated: abc1234 -> def5678
• Completed module update run. Replacements made: 1

Scope

• Improve runtime output only (no behavior changes to update logic)
• Keep logs concise and machine-readable where practical
• Preserve existing WARN, SKIP, and ERROR semantics

Proposed changes

1. Add stage-level logs:

• Manifest loaded
• Discovery started/completed
• Per-module processing started/completed
• PR creation step started/completed

2. Add per-module summary lines:

• Module name
• Module type (github or registry)
• Previous resolved ref/version (if detectable)
• New resolved ref/version
• Outcome: updated, unchanged, skipped, error

3. Add consistent prefixes for scan-friendly logs:

• INFO for normal progress
• WARN for non-blocking issues
• SKIP for intentionally skipped modules
• ERROR for failures

4. Add final run summary block:

• Modules total
• Updated
• Unchanged
• Skipped
• Errors
• Files touched
• Replacements made

Acceptance criteria

• A first-time user can understand workflow progress without reading source code.
• Logs clearly distinguish unchanged vs skipped vs failed modules.
• When replacements are zero, logs provide likely causes (for example no newer version, source_prefix mismatch, target selection mismatch).
• Existing tests continue to pass.
• New tests cover the new output formatting where appropriate.