Change Request: Tiered SW Platform (Operating System) Integration Process for Eclipse S-CORE

### Related

* https://github.com/eclipse-score/score/issues/1691
* https://github.com/eclipse-score/score/issues/1691#issuecomment-3290686184
* https://github.com/eclipse-score/score/issues/855
* https://github.com/eclipse-score/score/pull/1541

### Change Request Type

- [x] Feature Request/Modification
- [ ] Component Request/Modification

### Reason for the Change Request?

Currently, in Eclipse S-CORE, there is no sufficient answer to these questions:

* Which operating systems shall the software created in Eclipse S-CORE run on?
* Which service level can a consumer (user/integrator) assume for an operating system?
* Which service level is required by an operating system provider?
* How to onboard a new platform?

### How is the change realized?

We propose the inclusion of a tier based SW platform (operating system) definition as described here: https://github.com/eclipse-score/score/issues/1691#issuecomment-3290686184.

Note: Hardware is not included in this proposal.

#### Process Changes

The S-CORE process needs to include new definitions on:

* What a SW platform (operating system) is and is not
* Impact of operating system (per tier) on change requests
* Operating system Change/Inclusion Request (change platform tier, include a new platform, etc)

#### Architecture

The architecture specification needs to contemplate the inclusion of operating systems (per tier) in its discussions, based on process changes.

The architecture specification may need to have definition of each tier in its document, the list of operating systems per tier, etc.

#### Bazel Tooling

There are required changes in some bazel repositories,such as [bazel_platfotms](https://github.com/odra/score-bazel_platforms):

* list supported platforms
* organize it in a way that reflects the tier based setup
* **Q:** There is an open question on how this should reflect on bazel platform constrains: should the repository just "label" platform per tier or should that reflect in smart usage of constrains when triggering bazel builds (so tiers can be automatically filtered, etc).

### Affected work products

- [ ] Requirements are affected by this change?
- [ ] Architecture are affected by this change?
- [ ] Analysis are affected by this change?
- [ ] Detailed Designs are affected by this change?

### Impact analysis

## Type of Change Request

New Feature/Component

## Dependencies on other Change Requests

* https://github.com/eclipse-score/score/issues/855

## Estimates for realization

* Change request issue template needs to incorporate a "SW Platform (operating system) Request" type
* Any related process change request documents
* Architecture specification
* Bazel tooling (bazel_platformts, reference_integration, IFT, etc)

### Impacted Roles/Teams

* Tech Leads
* Architecture
* Operations (Tooling, CI, etc)

### Milestones

* clear definition of SW Platforms (operating system) and its tiers in S-CORE architecture specification and process definition
* tooling and bazel changes such as bazel_platforms

## Potential Impact on Security

No impact.

## Potential Impact on Safety

No impact.

### Safety or Security relevance

- [ ] Safety relevant
- [ ] Security relevant

### ASIL classification

_No response_

### Expected Implementation Version

1.0