Makefile.common: add -fno-strict-aliasing

[badochov]

Newer versions of GCC take advantage of strict aliasing rule that we break, without explicitely warning about it.

JIRA: RTOS-927

Description

Motivation and Context

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: (list targets here).

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work (list the PRs, preferably in merge-order).
• I will merge this PR by myself when appropriate.

[github-actions]

Unit Test Results

7 725 tests  +2   7 010 ✅ +2   37m 9s ⏱️ - 1m 42s
  445 suites +2     715 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit a758162. ± Comparison against base commit 2dc9570.

♻️ This comment has been updated with latest results.

[Darchiv]

Probably the best "solution" for now, even though this applies to the whole build. @nalajcie Do you see any drawbacks?

[nalajcie]

maybe add comment regarding WHY this is needed, for example:
messages are commonly type-punned - avoid GCC optimizations that might break if strict aliasing rules are not adhered to (or something shorter)

probably the same option should be set in CXXFLAGS (compilation flags for C++ programs)

[Darchiv]

Shouldn't this commit be tagged with RTOS-932 (or in addition to the existing task)?