feat: export UARTs to Ariel

[chrysn]

(Built on #67, please ignore the first two commits)

This builds up UARTs to be useful with Ariel OS in a way that avoids the need for pins.rs in applications (which I think is part of the purpose of board descriptions: to enable generic applications to run on any board, no matter whether the application or the board description is out-of-tree).

Concrete changes:

• I'm making serde strict. If this is controversial, I'll move it out into another commit, but I think it matters, for Ariel has already started racking up various "alternative syntaxes" for active-high/low. (Those are not cleaned up here yet, just avoiding the issue gets worse) [edit: dropped on reviewer request]
• "host_facing" is defined as a new property. This is an important property, because boards may have all kinds of UARTs (to on-board devices, to extension ports, to the debugger or to USB), and the latter two are the ones an application that offers, say, a shell, or debug output, or (in my case) a serial line network uplink wants to select.
  • In an extra commit, that is turned into a has_ property, so laze can filter on such a port's presence to decide if an application makese sense to build there.
• Allow annotating which UART devices go with which UART-as-defined-so-far (i.e., pair of TX/RX pins). See comment there -- at some point, this could be automated.
• Finally, UARTs get exposed to Ariel. Conveniently, this change does not need to lockstep with Ariel, because as long as no devices declare their MCU periph, nothing gets gen'd

[chrysn]

Rebased, cleaned up, and added a test.

Now not based on the problematic #67 series any more.

Having this in (and ideally released) would make it practical to turn ariel-os/ariel-os#1613 into a reviewable state.

[ROMemories]

I haven't looked at the rest.

[ROMemories]

Generally I think we should have the matching implementation in Ariel OS before landing this.

[chrysn]

Generally I think we should have the matching implementation in Ariel OS before landing this.

How? That'd be a chicken-and-egg situation. We can add code in Ariel OS, but that will have dead code until it is also added to the boards, and the boards can't have it until we update which sbd version it uses.

There is an open PR that uses it, ariel-os/ariel-os#1613, but that depends on this PR. I think that's the sensible sequence: PR here (done), test in Ariel in that PR (done), merge this, release sbd (it doesn't change output unless one does place the UARTs in the descriptions), merge the Ariel PR (including updated board files, so we never merge untested code).

[chrysn]

Rebased onto main; I think all comments are addressed.

[kaspar030]

Hm, so this is clearly chip specific meta info. We'll have to move this there (at some point). Let's go with it for now.

[kaspar030]

What's the next step? probably a version of ariel-os/ariel-os#1613 with just the uart changes.