Properly/consistently document the use/need of mcore_clk bootenv/clk-imx8m{m,n,p}.mcore_booted Kernel commandline flag.

[s-hemer]

          This is actually mysterious: it does  ```setenv mcore_clk clk-imx8m{m,n,p}.mcore_booted``` which is handed over to Kernel command line. 

BUT: it sets it just once and not persistently (so for loading M-core firmware from Linux that must be set always?) and, at least from my quick trail (hello_world only), not setting it when having the M core already started in u-boot does not let the M core crash (that was my initial guess: that it is relevant for preventing a crash when proceeding with the boot). The EVK configs in uboot-imx have this command, yet the AN5317 says at the note in 9.1.1: "By default, NXP Linux BSP keeps the root clock enabled for the M core when it is started from U-Boot". Additionally, it does not highlight the need of this parameter in 9.1.1.3 "Booting firmware early using U-Boot...".

_Originally posted by @s-hemer in https://github.com/phytec/doc-bsp-yocto/pull/102#discussion_r1409447033_

[s-hemer]

One very useful point would be to highlight that the equivalent of running the "run prepare_mcore" is to set mcore_clk=clk-imx8m{m,n,p}.mcore_booted, i.e. in bootenv.txt (like overlays) for permanent solution.

[s-hemer]

Some more tests imply that the flag is only needed if the M core was started in uboot (so the running firmware survives the boot to Linux). It is not needed for loading firmware through remoteproc.

Concluding, I would argue that the prepare_mcore just bloats the BSP: instead update the docu to just set the mcore_clk variable by either run the setenv command directly (it is also just one step that isn't that much longer) or put the line into bootenv.txt (mcore_clk=clk-imx8mp.mcore_booted). Additionally, it is somehow misleading as i.e. a real preparation (for loading a firmware for debugging via GDB) would be the M core startup via bootaux 0x1ffe0000 0.