[#666] Add Quality Declaration

[elBoberido]

Notes for Reviewer

This PR adds a quality declaration similar to the one from iceoryx classic.

Pre-Review Checklist for the PR Author

• Add sensible notes for the reviewer
• PR title is short, expressive and meaningful
• Consider switching the PR to a draft (Convert to draft)
  • as draft PR, the CI will be skipped for pushes
• Relevant issues are linked in the References section
• Every source code file has a copyright header with SPDX-License-Identifier: Apache-2.0 OR MIT
• Branch follows the naming format (iox2-123-introduce-posix-ipc-example)
• Commits messages are according to this guideline
  • Commit messages have the issue ID ([#123] Add posix ipc example)
  • Commit author matches Eclipse Contributor Agreement(and ECA is signed)
• Tests follow the best practice for testing
• Changelog updated in the unreleased section including API breaking changes
• Assign PR to reviewer
• All checks have passed (except task-list-completed)

Checklist for the PR Reviewer

• Commits are properly organized and messages are according to the guideline
• Unit tests have been written for new behavior
• Public API is documented
• PR title describes the changes

Post-review Checklist for the PR Author

• All open points are addressed and tracked via issues

References

Closes #

[Copilot]

Pull Request Overview

This PR adds a quality declaration for the iceoryx2 repository by introducing a new quality levels document and updating the README to reference it.

• Added a "Quality Levels" section with an overview table in the README.md.
• Created a new file (QUALITY_LEVELS.md) that details the quality levels based on ROS standards.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
README.md	Added a link and a new section explaining quality levels with a comparison table.
QUALITY_LEVELS.md	New file that describes each quality level and its requirements.

Comments suppressed due to low confidence (2)

README.md:333

• [nitpick] Consider using the plural form 'Quality Levels' in the link text for consistency with the section title and overall documentation.

[Quality level](./QUALITY_LEVELS.md) are 5 to 1+, where 1+ is the highest level.

QUALITY_LEVELS.md:1

• [nitpick] Consider capitalizing 'levels' to 'Levels' to match the styling used in the README and maintain consistency across documentation.

# Quality levels

[elfenpiff]

I would state that it runs on every supported platform and then we link to the list of supported platforms.

[elfenpiff]

The provided link does not state anything about SWE.6 tests, what are they, how are they defined. This needs to be at least linked.

[elfenpiff]

We should also link our version policy (semver) so that it is clear what is meant by that.

[elfenpiff]

This is quality level 5. This is a minimum.

For this and the static code analysis we should define what we mean by that. In this case, follow clang-format or rustfmt.

[elfenpiff]

This is quality level 5 but we can restrict this to: Rust (clippy, no compiler warnings and miri), C++/C (clang-tidy, address/undefined behavior/thread sanitizer, no compiler warnings)

[elfenpiff]

I would remove this statement and would in every quality level maybe add: conforms with ros2 quality level X.

Also we could state then things like: conforms with ISO 26262 ASIL-D (later) and add also other standards.
Those things have an actual meaning.

[elfenpiff]

What is a regression policy.

[elfenpiff]

Isn't full statement coverage a subset of branch coverage? So branch coverage would suffice?!

[elfenpiff]

Remove this line. I would not reference ROS2 here. They are, in my opinion, not a valid reference for code quality.

[elfenpiff]

We use nowhere quality level 3. Should we then merge quality level 2 with 3? Also 1 and 1+ are a bit weird.
I would make this its own normal quality level.

So it would be:

• 1+ -> 1
• 1 -> 2
• 2 and 3 -> 3
• 4 -> 4
• 5 -> 5