refactor: clean up code organization and refactor workflows to be extensible via image config files.

[sirutBuasai]

CI/CD Workflow Refactor

This PR refactors the entire CI/CD system from 70+ bespoke workflows into a composable, layered architecture.

What changed

Three-layer workflow composition:

• Caller workflows (pr-*, autorelease-*) — handle triggers, schedules, and change detection. They decide what to build and when, but contain zero test logic.
• Pipeline workflows (*.pipeline.yml) — one per framework. Orchestrate the build → test → release sequence. They decide which tests to run based on boolean inputs from the caller.
• Reusable test workflows (_reusable.*, *.tests-*) — single-purpose building blocks that run one test suite. They accept a config file + image URI, derive everything else internally.

Config-driven builds:

• One YAML config file = one released image variant. All version pins, Dockerfile paths, and metadata live in that file.
• Adding a new image variant = drop a config file. The discover-configs matrix automatically picks it up — no workflow changes needed.

Simplified administration:

• Changing a release schedule = edit one cron line in a 30-line caller file.
• Enabling/disabling a test suite = flip one boolean in the caller's pipeline inputs.
• Adding a new framework = copy the SGLang pipeline as a template, create configs, done.

Code organization:

• scripts/docker/ — scripts that run inside containers (COPY'd into images)
• scripts/ci/ — scripts that run on CI runners (build hooks, wheel compilation, config parsing)
• Previously these were scattered across .github/scripts/, scripts/, repo root, and inline in workflows.

Dot-namespaced workflow files:

• sglang.pr-amzn2023.yml, vllm.autorelease-ec2-amzn2023.yml, pytorch.tests-multi-gpu.yml
• Frameworks are visually grouped in the file list. Cross-framework utilities prefixed with _.

Unix-style actions:

• Each composite action does one thing: build-image builds, resolve-image-uri resolves, check-image-exists probes, discover-configs globs. Simple inputs, simple outputs.
• The old build-image action accepted 15+ inputs and handled wheel caching, sccache, tag computation, and Docker build all in one. Now those are separate concerns (build hooks, dedicated scripts, action steps).

Key benefits

• PR workflow management is trivial. Choosing which images to test, what tests to skip, or what paths trigger a build is all in a short caller file with no test logic to wade through.
• Release scheduling is centralized. See .github/release_schedule.md for the full picture. Staggered to avoid GPU fleet contention.
• Framework migration is mechanical. The pattern is proven across all 7 frameworks. Adding PyTorch 2.12 = add configs + update the glob pattern.
• Test logic is framework-agnostic where possible. Sanity, security, telemetry, and EFA tests work identically across all image types via the config-file interface.

What to look at

1. .github/config/image/ — all 21 image configs. One file = one image.
2. *.pipeline.yml — one per framework. This is where the build → test → release graph lives.
3. _reusable.sanity-tests.yml — example of how shared tests derive everything from config.
4. Any pr-*.yml — example of how callers are now just triggers + change detection + pipeline call.