feat: Add meta-chromium-test layer with CI/CD infrastructure

[caneraltinbasak]

This commit introduces a complete testing ecosystem for Chromium and Electron builds on embedded Linux systems, featuring a new Yocto/OpenEmbedded layer (meta-chromium-test) and AWS-based CI/CD infrastructure that supports automated builds, testing, and validation across multiple architectures and display backends.

The new meta-chromium-test layer provides a full Yocto/OpenEmbedded testing infrastructure with proper layer structure, supporting ARM, AArch64, RISC-V, and x86-64 architectures across multiple display backends including Ozone Wayland, X11, and Ozone X11. The layer uses KAS for reproducible build system configuration management and automatically adapts to the current meta-browser branch, whether it's scarthgap, master, or other versions. This eliminates the need to maintain separate configurations for each Yocto version.

The testing components include smoke test suites for automated Chromium and Electron functionality validation, QEMU integration for emulated testing environments across all architectures, and BitBake recipes for chromium-tests and electron-tests packages. The layer includes validation scripts that provide a framework for build and test validation, ensuring reliability across the entire testing pipeline.

The AWS-based CI/CD infrastructure provides scalable build capabilities through EC2 auto-scaling that dynamically provisions build runners based on workflow demand. The system includes automatic resource cleanup preventing orphaned infrastructure costs, EFS shared caching for distributed sstate-cache and downloads across all build nodes, and S3 artifact storage for persistent storage of build artifacts and test results. This infrastructure supports matrix-based parallel builds covering all combinations of browser, architecture, and display backend, with each matrix combination running in an isolated environment where individual failures don't block other combinations.

The workflow architecture consists of five GitHub Actions workflows that orchestrate the complete build and test pipeline. The main build/test workflow includes an 11-hour timeout to accommodate long Yocto builds, while dedicated EC2 infrastructure management handles resource provisioning. Browser-specific workflows for Chromium and Electron provide targeted testing, and automated EFS cache cleanup runs weekly to prevent cache bloat. The system supports both AWS-based auto-scaling and self-hosted runners, providing flexibility when AWS infrastructure is unavailable.

Build optimization features include shared sstate-cache that reduces build times through artifact reuse, persistent downloads caching for fetched sources across builds, and automated weekly cleanup preventing cache bloat. The multi-node scaling capability distributes builds across multiple EC2 instances, while automatic provisioning creates EC2 instances on-demand for build jobs. Resources are automatically terminated after builds complete, implementing a pay-per-use model with automatic resource lifecycle management.

The testing validation system includes built-in smoke tests that verify basic Chromium and Electron functionality, QEMU emulation that runs tests in environments matching target architectures, and build validation checks ensuring successful compilation and packaging. Detailed failure analysis and artifact collection provide error reporting when issues occur.

This testing matrix supports all combinations of three architectures (ARM, AArch64, x86-64) with both Chromium and Electron browsers across multiple display backends. Chromium supports Ozone Wayland and X11, while Electron supports Ozone Wayland and Ozone X11, all built against glibc (musl support was removed for simplicity). The KAS file generation system uses script-based creation of configuration files with a template system ensuring consistent configuration across all combinations, making it easy to add new architectures or backends while maintaining efficiency through a single source of truth for configuration patterns.

[caneraltinbasak]

OSSystems needs our key in github configuration, to be able to trigger this job from your repository. We can discuss this with e-mail.

I've updated chromium to Chromium138 and also added a recipe for Electron37. They are all dependent on each other(and this commit). I can't do stacked PR's because I can't create branches on your repo. How would you like me to push these for review?