build: remove program headers from first loadable segment

[badochov]

Program headers should not be loaded into kernel as there is no use for them. Previously starting kernel at start of memory region required explicit linker script.

JIRA: RTOS-908

Description

On all platform but ARM, program headers are placed in loadable segment before _init section. Resulting from this _init section start address isn't start address of first loadable segment. Due to that in PLO we may not be able to find proper segment for kernel if an address of the section that the kernel is to be loaded to = VADDR_KERNEL_INIT. Because of this additional linker script was required for sparc in kernel.

On ARM we headers weren't loaded most probably because of a bug(or very fortunated accident) in our binutils patch.
THe change introduced new file armelf_phoenix.sh but did't use it (ld/configure.tgt), instead it used armelf by default which defines EMBEDDED to true resulting in headers not being included.

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 700 tests  ±0   6 985 ✅ ±0   38m 50s ⏱️ -29s
  436 suites ±0     715 💤 ±0 
    1 files   ±0       0 ❌ ±0 

Results for commit 682c77d. ± Comparison against base commit b8de910.

♻️ This comment has been updated with latest results.

[lukileczo]

LGTM

[nalajcie]

please don't use semantic commit messages, this is not in our coding standard (they don't help creating changelog in case of superproject)

[badochov]

please don't use semantic commit messages, this is not in our coding standard (they don't help creating changelog in case of superproject)

FIxed

[nalajcie]

please don't use semantic commit messages, this is not in our coding standard (they don't help creating changelog in case of superproject)

FIxed

Thanks.
Just for reference: we might think about semantic commit messages if/when we will switch to monorepo, right now we do generate changelog from the PR descriptions (Types of changes section) - which is not ideal (as one PR might fix/add new feature simultaneously)) - for example: https://github.com/phoenix-rtos/phoenix-rtos-project/releases/tag/v3.2.0