Feature Request for virtual integration environment

## TLDR;

S-CORE should initially support the following virtual integration targets:
- Linux containers, eg. docker
- VMs running QNX SDP 8.0
- VMs running a Linux distribution

Functionally the following should be possible:
- container creation
- VM creation
- building applications for a specified virtual target
- running containers/VMs from a unified Bazel command
- running containers/VMs and their lifecycle managment available programatically for [ITF](https://github.com/eclipse-score/score/issues/200)

## Description

[Integration Test Framework, a.k.a ITF](https://github.com/eclipse-score/score/issues/200) is a set of extensions on top of pytest that allow to interact with "targets", whatever those "targets" are. ITF itself does not provide (and should not) any particular runtime environment for application deployment and execution. However, without a "target" it is impossible to run and test the application developed as different components for the S-CORE platform. In order to achieve this, basic runtime environments could to be provided alongside ITF:
- virtual environment
- hardware environment

Hardware environment is out of scope for this feature request, and should be introduced, if needed, by another feature request. However, care needs to be taken that the integration tests written in ITF, are developed against a unified target API, allowing seamless execution of the tests against any type of execution environment.

### Virtual environment

The focus of this feature request is providing a virtual environment for S-CORE component execution. Dimensions mainly considered when defining the possible virtual environments are:
- development usability
- resource consumption
- runtime constraints

The **runtime constraints** are predefined by the runtime execution environment currently chosen by the S-CORE architecture, which are:
- Linux
- QNX

The **development usability** and **resource consumption** dimensions could be covered by two approaches:
- Containers (Linux only environment)
- faster development times
- less resource usage, host like execution
- possible implementations: docker, podman
- Virtual machines (Linux or QNX)
- slower development times
- more resource usage
- dependency to virtualization support for particular runtime architecture (e.g. x86 vs ARM)
- possible implementations: qemu

### Test scope
Having different runtime environments available allows to scope the tests to different use cases, e.g.:
- running one application in a container
- running multiple applications that communicate using a particular IPC implementation in one container
- running multiple containers that communicate over network
- running VM with QNX applications and testing startup behavior
- running multiple VMs with QNX applications connected over network

etc.

### Development plan
First phase of development should focus on supporting containers as the runtime environment. Developers should be able to build their applications, package them in docker containers and use ITF to bring the steps together in order to write their functional tests. The exact initial scope and possible follow up steps should be defined in
- https://github.com/eclipse-score/score/issues/170

Second (parallel) phase of development should bootstrap the QNX toolchains for both building the applications, as well as constructing runnable QNX images. Additionally, a plugin for ITF needs to be developed to run the virtual images. Scope of this phase should be detailed in:
- https://github.com/eclipse-score/score/issues/171
- https://github.com/eclipse-score/score/issues/172

Running Linux based virtual machines is currently not treated as a priority, because part of the functionality can be covered by running. container images. In the future, this feature request might be extended, or a new feature request might be created.