Enforce architecture review on major changes and new features, APIs and tooling

[nashif]

Introduction

In a large open-source project like Zephyr, an architectural review is required for changes or contributions that significantly affect the core design, system integrity, or long-term maintainability of the project.
While some of the review is covered in pull-requests, changes are often not visible enough and not getting enough reviews and feedback from the wider community.

Problem description

The goal here is not to block progress and delay introduction of new features, but to make sure significant changes and additions receive the visibility they deserve and are not merged prematuerly without proper feedback and vsibility.

Proposed change

The types of contributions requiring architectural review include:

1. Core Infrastructure Changes
   Significant modifications and overhaul to critical components such as the kernel, scheduler, or memory management.
   Changes in low-level APIs (e.g., driver or device management APIs).
   Introduction of new mechanisms that affect synchronization, interrupts, or threading models.

2. New Subsystems or Features
   Proposals to add entirely new subsystems or significant features (e.g., new networking stacks, file systems, or IPC mechanisms).
   Extensions that require changes to multiple modules across the system.

3. Changes to Public APIs
   Adding, removing, or significantly altering public APIs that are used by applications or external components.
   Modifications that affect backward compatibility or could result in breaking changes for existing users.

4. Cross-Subsystem Changes
   Changes that touch multiple subsystems or require coordination between different maintainers.
   Enhancements that alter how different parts of the system interact or communicate (e.g., changes to power management frameworks or configuration systems).

5. Build and Configuration System Changes
   Significant changes to the CMake build system or Kconfig configuration system.
   Proposals affecting how users build, configure, or deploy Zephyr-based applications.

6. Security and Trust Model Changes
   Enhancements that affect the system’s security model (e.g., changes to the trusted execution environment, secure boot, or encryption).
   Modifications to access control mechanisms or permissions.

7. Portability and Platform Support
   Adding support for new architectures, processors, or instruction sets.
   Changes that affect how the system supports multiple platforms or architectures.

8. Standards Compliance
   Contributions aiming for compliance with industry standards (e.g., POSIX compliance, real-time certifications like MISRA, or safety standards like ISO 26262).

9. Major Performance Optimizations
   Optimizations that significantly alter core code paths or algorithms, especially those that affect timing, latency, or power consumption.

10. Additions and Changes to Tooling
    Changes in behaviour and scope of West, Twister and other user facing tools.
    Addition of new features to build and configuration tooling such as the addition of new west subcommand, build targets in the build system and extenstions to existing tooling

11. Deprecations or Major Refactoring
    Deprecating existing features, modules, or APIs.
    Major refactoring of code that could impact stability or maintainability.