STM32 EXTI Rework

[KozhinovAlexander]

Rework STM32 Zephyr EXTI driver to be independent from GPIO and compatible with most of the STM32 SoC's.

Addresses the issue #85366

This change introduces updated EXTI interrupt controller supporting interrupt/event lines handling also from peripherals.

The simplest way to test this PR under Linux is to run tests by utilizing following script:

Create a script file:

touch <zephyr_root_path>/exti_build_test.sh 
chmod +x exti_build_test.sh  <zephyr_root_path>/exti_build_test.sh 

Copy following content to the script:

# Put your board under test to this list
board_list=(
	"nucleo_h745zi_q/stm32h745xx/m7"
)

# The apps are defined for this application
app_list=(
	"tests/drivers/interrupt_controller/intc_exti_stm32"
	"tests/drivers/gpio/gpio_basic_api"
	"tests/drivers/rtc/rtc_api"
)

sleep_time_sec_list=(
	1
	20
	60
)

script_path="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# Iterate over boards:
for board in "${board_list[@]}"; do
	# Iterate over apps:
	for i in "${!app_list[@]}"; do
		app="${app_list[$i]}"
		app_abs_path="$script_path/$app"
		build_dir="$app_abs_path/build/$board"
		echo "--> use build directory: $build_dir"

		west build -p auto -d $build_dir -b $board $app_abs_path
		[ $? -ne 0 ] && exit 1;

		west flash -d $build_dir
		[ $? -ne 0 ] && exit 1;

		echo "--> wait ${sleep_time_sec_list[$i]} sec. for $board $app to finish..."
		sleep ${sleep_time_sec_list[$i]}
		done
done

exit 0;

NOTE: You may need to change the board name in board_list.

Run the script: <zephyr_root_path>/exti_build_test.sh

[KozhinovAlexander]

@erwango Do you have ability to run all the EXTI/GPIO twister tests for different stm32 SoC on HW for this PR?

[erwango]

First, a big thanks for addressing this point.

@erwango Do you have ability to run all the EXTI/GPIO twister tests for different stm32 SoC on HW for this PR?

Yes, but we're currently busy with v4.1, so this topic will be addressed in low prio.

Then, one observation regarding the whole change.
I know this is WIP, but I've seen similar things already which can end up with lot of work achieved but never integrated, resulting in lot of frustration in both sides.
So here is my advice:
Even in WIP, please split your changes in multiple commits to explain the changes you're doing.
This may not be possible for some parts, and there will be fixup commits, which is ok on a WIP branch.
But it will help readers to understand where you're going, the big directions, and early prevent misalignments that would prevent eventual merge.
Otherwise, if you're not abl to do so, then maybe this is a bit early to share your work

For instance: here is an example of good draft PR: https://github.com/zephyrproject-rtos/zephyr/pull/85135/commits
(You'll see it's quite clean, I don't ask so much, but at least reader can understand the direction and is able to comment)

[KozhinovAlexander]

@erwango Thanks for the advice. I have a commit-split definitely on my to-do list. I didn't do so, cause I have somehow cyclic dependency:

1. I need a CI with all the tests to proceed faster - thus I've created a WIP
2. I myself was not sure how the end work will look like until I've approached to some good shape of this work. But to approach to good shape I needed tests from CI (see 1.) :)

I hope you see my point. Sure I will split commits - thanks for the reminder ;)

[KozhinovAlexander]

@mathieuchopstm Thanks for the review - I've applied changes so far. Please take a look.

[KozhinovAlexander]

@henrikbrixandersen @bjarki-andreasen please ignore last review request - the git-hub app on the smartphone didn't worked as expected.