samples: drivers: spi_flash: fix compilation

[JordanYates]

Fix two issues relating to compilation of this sample:

• Missing EXMIF driver support on nRF54H
• Missing spi-flash0 alias on STM development kit

Resolve the second by removing the requirements for the alias, and then removing it from all boards, as this is the only application that uses it.

[JordanYates]

This change fixes the sample for every board in tree:

(.zephyr_venv) jordan@computer:~/code/zephyr$ ./zephyr/scripts/twister -T zephyr/samples/drivers/spi_flash --all
ZEPHYR_BASE unset, using "/home/jordan/code/zephyr/zephyr"
Renaming output directory to /home/jordan/code/zephyr/twister-out.2
INFO    - Using Ninja..
INFO    - Zephyr version: v3.6.0-4669-gc7f1b27458df
INFO    - Using 'zephyr' toolchain.
INFO    - Selecting all possible platforms per test case
INFO    - Building initial testsuite list...
INFO    - Writing JSON report /home/jordan/code/zephyr/twister-out/testplan.json
INFO    - JOBS: 28
INFO    - Adding tasks to the queue...
INFO    - Added initial list of jobs to queue
INFO    - Total complete: 1466/1466  100%  skipped: 1344, failed:    0, error:    0
INFO    - 2 test scenarios (1466 test instances) selected, 1344 configurations skipped (778 by static filter, 566 at runtime).
INFO    - 122 of 1466 test configurations passed (100.00%), 0 failed, 0 errored, 1344 skipped with 0 warnings in 147.07 seconds
INFO    - In total 0 test cases were executed, 1466 skipped on 733 out of total 734 platforms (99.86%)
INFO    - 0 test configurations executed on platforms, 122 test configurations were only built.
INFO    - Saving reports...
INFO    - Writing JSON report /home/jordan/code/zephyr/twister-out/twister.json
INFO    - Writing xunit report /home/jordan/code/zephyr/twister-out/twister.xml...
INFO    - Writing xunit report /home/jordan/code/zephyr/twister-out/twister_report.xml...
INFO    - Run completed

[kartben]

Resolve the second by removing the requirements for the alias, and then removing it from all boards, as this is the only application that uses it

is this really what we want though? By that logic we should also remove things like watchdog0, pwm_led0 then? And how about boards that may have multiple SPI flash chips? I think being able to indicate what is the "main" SPI flash kind of makes sense

[JordanYates]

I misremembered the conversation in #72519 concerning the support for removing the alias.

I would argue the alias doesn't provide much value, I would expect that any application complex enough to use two external flashes is not operating through a flash0 flash1 alias. Mostly because the names provide no information on the differences between the two.

I would also expect that most complex applications are running through the flash map API anyway, as writing directly to flash is obviously risky without defined areas for different systems.

The cost of keeping it is going to be repeated CI failures whenever a board is added that has an external flash but doesn't populate the alias. Not a high cost, but annoying.

[JordanYates]

Rebased due to file conflicts