GitHub CI workflow contains significant duplication and could be simplified

The current GitHub Actions workflow (Build_CI) has grown considerably over time and now contains a large amount of duplicated YAML. While the workflow is functional, the repetition makes it difficult to maintain and increases the effort required to introduce new build configurations or update existing ones.

Some observations:

Common Windows build steps are duplicated across many jobs. The sequence of checking out the repository, enabling long paths, running api_check.sh, creating the build directory, configuring CMake and building is repeated with only minor differences in CMake options. Ubuntu jobs also contain extensive duplication. Several jobs repeatedly install the same development packages, run the same pre-build checks and perform nearly identical configure/build steps, differing only in a small number of build options. Dependency installation is repeated in many Linux jobs using identical or nearly identical apt-get install commands. The same API checks are executed repeatedly in many jobs using identical shell snippets. Many jobs differ only in a handful of CMake options, while the surrounding workflow remains identical. This suggests that several of these jobs could potentially be expressed as build matrices rather than separate job definitions.

Possible improvements include:

introducing reusable workflows (workflow_call) or composite actions for common setup and build logic, using build matrices where jobs differ only by configuration options, centralizing dependency installation into reusable scripts or composite actions, reducing duplicated CMake command lines by collecting common options.

Such a refactoring would reduce maintenance effort, make the workflow easier to extend, and help ensure that common build logic remains consistent across all configurations.