[misc] AArch64 improvements and fixes

[carlocaione]

Moving here several points raised by @jharris-intel in #30676 and not really related to that PR.

#30676 (comment)
#30676 (comment)
#30676 (comment)
#30676 (comment)

[carlocaione]

tagging the relevant people @MrVan @jharris-intel @npitre

[carlocaione]

@jharris-intel about your comment:

We start in EL3, but EL2 is implemented.

In this mode we need to do some EL2 setup also. 

After you setup for EL2 do you drop into EL2 or directly into EL1?

[jharris-intel]

After you setup for EL2 do you drop into EL2 or directly into EL1?

The current hacked-together local changes skip the existing EL2 setup entirely, and as such drop directly into EL1's setup code in __start from EL3's setup code.

This was only because I was trying to avoid changing __start itself if at all possible, which meant I was unable to avoid this. As a result I had to replicate portions of the EL2 setup code in z_arch_el3_plat_init.

Ideally, EL3 setup would drop into the next implemented EL. That is, something along the lines of the following:

1. Assert that the current EL is implemented.
2. Check if the current EL is the highest implemented EL. If so, call a routine that does anything that must be done at the highest implemented EL.
3. Do any setup in particular for this EL.
4. Return to the next lower implemented EL's setup code.

[carlocaione]

What about simply having a weak z_arch_plat_init(current_el, is_highest) to be called by the reset code at each descending Elx. The platform can then use that as it please.

[carlocaione]

Closing this because this are being taken care of in #32394