Migrate from JSON Build Specs to YAML Image Templates

[arodage]

Merge Checklist

All boxes should be checked before merging the PR

• [*] The changes in the PR have been built and tested
• [] Ready to merge

Description

This PR migrates the Image Composer Tool from JSON build specifications to YAML image templates as the primary input format, simplifying the architecture and improving usability.

Key Changes

1. New YAML Template Format

• Introduced ImageTemplate struct with image, target, and systemConfigs sections
• Added helper methods for clean data access (GetProviderName(), GetPackages(), etc.)
• Focused schema on core functionality (packages, kernel, target configuration)

2. Simplified Architecture

• Eliminated BuildSpec and used templates directly throughout pipeline
• Removed JSON parsing and validation complexity

3. Provider Updates

• Modified all providers (AzureLinux3, eLxr12, EMT3.0) to accept *ImageTemplate
• Updated Init() method signatures across provider interface
• Maintained existing package resolution and validation logic

4. Command Updates

• Updated build and validate commands to work with YAML templates
• Changed file completion to suggest only YAML files
• Enhanced validation output with template structure details

5. Documentation & Tests

• Updated CLI specification and README with YAML examples
• Comprehensive test coverage for template validation and processing
• Removed cache disabling options (caching always enabled)

Usage

New command format:

./image-composer build image-templates/azl3-x86_64-edge-raw.yml
./image-composer validate image-templates/azl3-x86_64-edge-raw.yml


<!-- Fixes # (issue) -->

#### Any Newly Introduced Dependencies
<!-- Please describe any newly introduced 3rd party dependencies in this change.
List their name, license information and how they are used in the project. -->

#### How Has This Been Tested? <!-- REQUIRED -->
<!-- Please describe the tests that you ran to verify your changes. Provide
instructions so we can reproduce. Please also list any relevant details for your
test configuration. -->

[magerstam]

why hard-coding these in the code rather than putting the valid combinations in the json schema itself and validate against the schema?

[arodage]

This is not for validation. Used in logging to get the provider name and, more importantly, for initializing the correct registered provider in executeBuild(). I still agree that this should not be hardcoded.
Would it be better to keep this mapping in a separate file?

[magerstam]

few minor comments to address