Refactor the current C/C++ compiler warning sets to establish a consistent warning policy aligned with MISRA-oriented development.

## Summary

The current warning configuration should be reviewed and restructured to provide a clear, maintainable, and consistent set of compiler warnings across supported C/C++ compilers and platforms. The new warning sets should prioritize diagnostics that help identify issues addressed by the MISRA C/C++ guidelines while avoiding compiler-specific inconsistencies and unnecessary noise.

This work focuses on compiler diagnostics and warning policy. Enabling compiler warnings alone does not constitute MISRA compliance; MISRA-specific static analysis and project-level compliance activities remain separate concerns.

## Goal
Establish a standardized C/C++ compiler warning policy that provides a strong foundation for MISRA-oriented development and can be consistently applied across S-CORE projects and supported toolchains.

The resulting warning sets should be structured, documented, and maintainable, with clear handling of compiler-specific capabilities and differences.

## Scope
The refactoring should cover:
TBD

## Proposed Deliverables
- Refactored and standardized C/C++ compiler warning sets
- Warning sets aligned with relevant MISRA C/C++ guidelines where compiler diagnostics provide applicable coverage
- Clearly defined warning levels and policy categories
- Consistent warning configuration across supported compilers
- Explicit handling of compiler-specific warnings and unsupported diagnostics
- Identification and documentation of warnings that cannot be enforced consistently across all platforms
- Validation of the new warning sets against representative S-CORE C/C++ targets
- Updated documentation describing the warning policy and its intended use
- Release notes documenting the changes and any migration considerations

## Validation Expectations
Before closing this issue, verify:
- The new warning sets can be applied successfully to supported C/C++ targets
- Relevant compiler diagnostics associated with MISRA-oriented rules are enabled where supported
- Warning configurations behave consistently across supported compiler/toolchain versions
- No unintended changes to compilation or linking behavior are introduced
- Existing projects can migrate to the new warning sets without unexpected build failures beyond newly enforced diagnostics
- Compiler-specific warnings are correctly guarded or isolated where required
- Representative S-CORE projects build successfully using the new warning policy
- Known gaps between compiler warnings and MISRA requirements are explicitly documented

## Acceptance Criteria
- A clearly defined and documented C/C++ warning policy is available
- Warning sets are refactored into a maintainable structure suitable for reuse across S-CORE projects
- Relevant MISRA-oriented compiler diagnostics are enabled where technically applicable
- Compiler- and platform-specific differences are handled explicitly
- Representative C/C++ targets are validated with the new warning sets
- Newly introduced warnings and required source-code changes are identified and documented
- The documentation clearly states that compiler warning configuration alone does not provide MISRA compliance
- Known limitations and MISRA rules requiring dedicated static analysis are documented

## Checklist
- [ ] Inventory the current C/C++ warning sets
- [ ] Identify duplicated, redundant, obsolete, or inconsistent warning options
- [ ] Map applicable compiler warnings to relevant MISRA C/C++ guidelines
- [ ] Define the target warning policy and categories
- [ ] Define required, recommended, and optional warnings
- [ ] Define handling for compiler-specific warnings
- [ ] Refactor warning configuration and Bazel integration
- [ ] Validate GCC warning behavior across supported GCC versions
- [ ] Validate warning behavior for supported non-GCC/vendor toolchains
- [ ] Build representative S-CORE C/C++ targets with the new warning sets
- [ ] Analyze newly reported warnings and required source-code changes
- [ ] Document warnings that cannot be consistently enforced
- [ ] Document MISRA rules requiring dedicated static analysis
- [ ] Update README/docs with the new warning policy
- [ ] Prepare release notes and migration guidance