Split out oss versions for e2e/integration tests

[brendankowitz]

Description

This pull request refactors the CI pipeline to run integration and end-to-end tests for the R4B and R5 OSS versions using Dockerized SQL Server and CosmosDB containers, rather than deploying and testing against live Azure environments. It introduces a new job template for running these tests in Docker and removes several deployment and test stages for R4B and R5 CosmosDB/SQL sites, streamlining the pipeline and improving test isolation and reproducibility.

Pipeline restructuring and test execution changes:

• Added a new job template docker-sql-tests.yml to automate building, running, and testing R4B and R5 projects against Dockerized SQL Server and CosmosDB containers, including secure password generation and code coverage reporting.
• Replaced the previous Azure deployment and test stages (deployR4B, deployR4BSql, deployR5, deployR5Sql, testR4B, testR5) with a single testOssVersionsDockerSql stage that runs Docker-based integration and E2E tests for both R4B and R5. [1] [2]

Coverage aggregation update:

• Updated the coverage aggregation stage to depend on the new Docker SQL test stage instead of the removed R4B/R5 test stages, ensuring coverage reports include results from the new test jobs.

Related issues

Addresses [issue #].

Testing

Describe how this change was tested.

FHIR Team Checklist

• Update the title of the PR to be succinct and less than 65 characters
• Add a milestone to the PR for the sprint that it is merged (i.e. add S47)
• Tag the PR with the type of update: Bug, Build, Dependencies, Enhancement, New-Feature or Documentation
• Tag the PR with Open source, Azure API for FHIR (CosmosDB or common code) or Azure Healthcare APIs (SQL or common code) to specify where this change is intended to be released.
• Tag the PR with Schema Version backward compatible or Schema Version backward incompatible or Schema Version unchanged if this adds or updates Sql script which is/is not backward compatible with the code.
• When changing or adding behavior, if your code modifies the system design or changes design assumptions, please create and include an ADR.
• CI is green before merge
• Review squash-merge requirements

Semver Change (docs)

Patch|Skip|Feature|Breaking (reason)