Add initialization banner with basic info

[fgr-17]

Description

This PR adds a simple banner that shows basic info from the host system and the container, for example:

═══════════════════════════════════════════════════════
  Ocre Runtime v0.99.0-dev
═══════════════════════════════════════════════════════
  Zephyr:    4.2.0
  Board:     nrf5340dk/nrf5340/cpuapp
  SoC:       nrf5340 (nrf53)
  Arch:      arm
  RAM:       32 KB heap
  WAMR:      175 KB
═══════════════════════════════════════════════════════

The banner is wrapped under kconfig variable called CONFIG_OCRE_PRINT_BANNER

Type of change

Please delete options that are not relevant.

• 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 not work as expected)
• Code cleanup/refactoring
• This change requires a documentation update
• CI system update
• Test Coverage update

How Has This Been Tested?

Tested output on native_sim, running:

./build.sh -t z -f <path-to-wasm-blinky>

This command shows the following output:

-- west flash: rebuilding
[2/2] Running utility command for native_runner_executable
-- west flash: using runner native
WARNING: Using a test - not safe - entropy source
E: Cannot create zeth (-2/No such file or directory)
*** Booting Zephyr OS build v4.2.0-32-g8d0d392f8cc7 ***
I: /lfs mount: 0

I: OCRE common initialized successfully
I: Registered cleanup handler for type 0
I: Timer system initialized
I: Registered cleanup handler for type 3
I: Messaging system initialized
I: Container Supervisor started.

ocre:~$

═══════════════════════════════════════════════════════
  Ocre Runtime v0.99.0-dev
═══════════════════════════════════════════════════════
  Zephyr:    4.2.0
  Board:     native_sim/native
  SoC:       native (undefined)
  Arch:      posix
  RAM:       64 KB heap
  WAMR:      500 KB
═══════════════════════════════════════════════════════

I: Request to create new container in slot: 0
I: Request to run container in slot:0
I: EVENT_CREATE_CONTAINER
I: Allocating memory for container 0
I: File path: /lfs/ocre/images/blinky.bin, size: 21068
I: Loaded binary to buffer for container 0
W: Created container:0
I: Created container in slot:0
I: EVENT_RUN_CONTAINER
I: Instantiating WASM runtime for container:0
I: Module registered: 0x80e8b00
W: Running container:0 in dedicated thread
I: Started container in slot:0
I: Container thread 0 started
=== Generic Blinky Example (Printf Only) ===
This example demonstrates software blinking without physical hardware.
I: Registered dispatcher for type 0: timer_callback
I: Incremented resource count: type=0, count=1
I: Created timer 1 for module 0x80e8b00
Timer created. ID: 1, Interval: 1000ms
I: Started timer 1 with interval 1000ms, periodic=1
Generic blinking started. You should see 'blink' messages every 1000ms.
Press Ctrl+C to stop.
blink (count: 1, state: -)
blink (count: 2, state: +)
blink (count: 3, state: -)
blink (count: 4, state: +)
blink (count: 5, state: -)
blink (count: 6, state: +)

Tested also with CONFIG_OCRE_PRINT_BANNER=n and validating that shows the former label

Test Configuration (required):

• Host OS type, version, and arch: docker container ghcr.io/zephyrproject-rtos/zephyr-build:latest on Ubuntu Server 20.04 (x64)
• Developer Board make & model: native_sim
• Board Tools Installed: -

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[fgr-17]

Note for the rev: this shouldn't crash if flash.bin doesn't exist for some reason

[fgr-17]

@kr-t is this PR ok or should I close it?

[kr-t]

I think we thought about this PR and planed to have something similar in the refactored Ocre. I assume, that even if we miss something and you'd like to add it, it would be easier and better to do it as a new PR. If you want to not forget about it, you can create a small issue mentioning this features/PR.

[kr-t]

I think the most important question for the future when we have all this info in the container, is how much we want to hide behind some capability if we make an app where we don't want to expose any arch info, for example.