Reduce generated cmdline.txt vs. refreshed cmdline.txt differences

It took me way too much time to understand why my Pi 4 B or my CM 4 would sometimes fail to boot (see #996915), and why I wouldn't get helpful error messages in those cases; and also to understand why the first boot would usually lead to lots of messages displayed on screen before it turns black and everything appears to be dead…

It happens that the image build prepends console=ttyS1,115200 in /boot/firmware/cmdline.txt, meaning the serial console gets listed before the default console=tty0. I'm not entirely certain this conditions where the initramfs prompt gets displayed (e.g. failure to find the root filesystem → getting dropped into an initramfs shell), but this seems likely.

In any cases, when raspi-firmware is reconfigured (upon the first boot), the serial console gets listed after the primary display, and I'd like us to get more consistency there.

The logic in the current bullseye page can be seen in z50-raspi-firmware:

• with the default CONSOLES=auto, we get console=tty0 first, then a possible serial console;
• otherwise, we get as many console=FOO for each FOO listed in CONSOLES.

We might change the current insertion of the serial console at the beginning of the command line with something along the lines of “locate the last console=FOO and append after that” but it seems cumbersome.

The way the cmdline.txt is constructed now (see z50-raspi-firmware), with the various console=FOO being listed in ${pre_cmdline}, it seems easier to just insert the serial console right before root=. This would mean having no condition at all regarding existing console= parameters (is there one at least? are there multiple ones? etc.), and having increased chances to have the serial console listed at the same place it will hold after the reconfiguration.

Does that seem sane? Any objections or better ideas?

(I'll try something along this way locally and see what happens.)

Edit: fixed ttyS0 → tty0 (= HDMI display)