boards/nucleo*: Cleanup and Enhance the Documentation

[crasbe]

Contribution description

Inspired by the work of grouping common code and the new *.doc.md syntax, I started to deduplicate the documentation of the STM32 Nucleo boards.

This PR includes:

• Add P-Nucleo-WB55 to Nucleo64 group
• Move Nucleo32 Boards to doc.md format done in boards: rename doc.txt -> doc.md for boards which name's starts from e to p #21641
• Move Nucleo64 Boards to doc.md format done in boards: rename doc.txt -> doc.md for boards which name's starts from e to p #21641
• Move Nucleo144 Boards to doc.md format already done in boards/nucleo-144: rename doc.txt to doc.md #21318
• Create common doc.md files for Nucleo32, Nucleo64 and Nucleo144
• Don't show the content of boards/common/nucleoXX/include/board.h in the Nucleo32/64/144 group
• Add Nucleo-common information to these files (such as the LED0<->SPI issue raised in nucleo-f446re problem with using the led and spi at the same time #21336 by @tanneberger).
• Create a boards/common/nucleo/flashing.doc.md page that contains about the Flashing process. superseded by doc/guides: add STM32 Flashing Guide #21767
• Replace the Flashing information for all Nucleo32 boards.
• Replace the Flashing information for all Nucleo64 boards.
• Replace the Flashing information for all Nucleo144 boards.
• Add Flashing information reference to the common pages.
• Add information about the UART connection to the common pages.
• Add information about the toolchain to the common pages. Decided against it.

Testing procedure

Check that the documentation looks beautiful.

Issues/PRs references

Depends on #21319. Update: now merged.
Depends on #21767. Update: now merged.

Progress for Tracking Issue #21220.

[crasbe]

Some of the Nucleo boards have a remark about the toolchain that is to be used:

RIOT/boards/nucleo-f303k8/doc.txt

Lines 81 to 84 in 48162bd

	## Supported Toolchains
	For using the ST Nucleo-F303K8 board we strongly recommend the usage of the
	[GNU Tools for ARM Embedded Processors](https://launchpad.net/gcc-arm-embedded)
	toolchain.

I wonder if that information is still relevant and should be added to the common files or if it's irrelevant and should be removed.

The Launchpad Link is outdated as well: Launchpad is no longer used for the Arm GNU Toolchain releases.

The toolchain is now maintained at Arm: https://developer.arm.com/Tools%20and%20Software/GNU%20Toolchain
But most(?) distributions provide an gcc-arm-none-eabi package. Maybe that would be better to mention?

[riot-ci]

Murdock results

✔️ PASSED

b6931af boards/nucleo-*: migrate to Flashing Guide, point to common doc

Success	Failures	Total	Runtime
1	0	1	01m:16s

Artifacts

• Documentation preview

[crasbe]

In #21794 (comment) I wrote that an OpenOCD update guide doesn't really belong in the guide...
Well:

RIOT/boards/nucleo-l552ze-q/doc.md

Lines 42 to 55 in 744d3c0

	@note The upstream version of OpenOCD doesn't contain yet support for this board,
	so the source code version from http://openocd.zylin.com/#/c/5510
	must be built to be able to flash this board (adapt the configure command with
	your preferred installation directory):
	```
	$ git clone https://git.code.sf.net/p/openocd/code openocd
	$ cd openocd
	$ git fetch http://openocd.zylin.com/openocd refs/changes/10/5510/5 && git checkout FETCH_HEAD
	$ ./bootstrap
	$ ./configure --prefix=<installation directory>
	$ make -j
	$ sudo make install
	```

Perhaps I should copy that and add it to the guide nevertheless 🤷‍♂️

Although this case underlines the reason for doing this change: That remark was added in 2020 and OpenOCD 0.11.0 from 2021 already supports that board. Hints like that tend to become quietly outdated unfortunately.

[crasbe]

Perhaps I should copy that and add it to the guide nevertheless 🤷‍♂️

I think this is the wrong spot. We should rather have a combined OpenOCD guide, but this is beyond the scope of this PR.

[AnnsAnns]

Oh heck, that's one gigantic PR

[crasbe]

Some typos.

[AnnsAnns]

Crasbe fixing the issues from Crasbes review of Crasbes PR 😛

[AnnsAnns]

😵‍💫 Given the repetitions I'm not completely surprised if I missed something but for the most part this looks good

[AnnsAnns]

Keeping in mind that the motor stuff appears to be handled in another PR, I'd still really like somebody else to also take a look at this before this gets merged, mostly because it feels like my brain goes into trance after the fifth board description and I don't feel confident enough to say that my review is enough.

I can say that it builds everything & looks alright in doxygen. Thank you for this PR :)

[Teufelchen1]

Scrolled through it in the aforementioned trance mode and found nothing to complain about. lgtm

[AnnsAnns]

Will this now have to wait for #20429? I don't think this can even be merged right now, due to the failing CI test for code that you didn't really touch.

[crasbe]

Will this now have to wait for #20429? I don't think this can even be merged right now, due to the failing CI test for code that you didn't really touch.

I updated the exclude pattern file that previously already included the warnings. The reason this popped up is that the warnings are now not in a group but in a file.