Adapt `smoltcp` to support stm32 target

[Tortoaster]

Het versturen van een bericht op de stm32 via smoltcp werkt als volgt:

1. smoltcp sockets houden hun eigen buffers bij, die je meegeeft zodra je ze aanmaakt. Deze buffers bevatten alle berichten die nog verstuurd moeten worden (en ontvangen zijn). Wanneer je een bericht send, zet smoltcp deze alleen klaar in die buffer, het echte versturen gebeurt pas later.
2. Het versturen kan via manual polling, of via een async background trask zoals embassy-net het doet. Wanneer dit gebeurt, vraagt de Device trait van smoltcp om een TxToken -- een buffer waar het te versturen bericht in moet komen, om later verstuurd te worden met de consume method.
3. Onze implementatie maakt deze TxToken van een ander type TxToken, namelijk die van embassy-stm32's Driver trait. embassy-stm32 checkt eerst of er ruimte is om een bericht te schrijven in de tx ring, en stuurt een TxToken terug als dat zo is.
4. Vervolgens consumeert smoltcp deze token, waarbij er eerst iets in de onderliggende buffer schrijft, en daarna via de token de STM instructies geeft het bericht echt te versturen.
5. Nadat het bericht echt verstuurd is, komt er een timestamp te staan in de tx descriptor ring van de STM.

Het doel is om deze timestamp op het juiste moment en voor het juiste bericht op te vragen, en die te returnen in de send_time_critical implementatie van de NetworkPort trait. Dit is een uitdaging, want zodra je een bericht send met smoltcp, vergeet je alle informatie over waarvandaan je dat bericht stuurt. Er is dus geen voor de hand liggende manier om, op de plek van manual polling of in de background task, te achterhalen welk bericht er net afgehandeld is, en of dat bericht nog steeds wacht op een timestamp (via send_time_critical) of niet (via send). Bovendien moet de juiste timestamp dan nog opgehaald worden. Dat is dat niet de taak van smoltcp, maar wel iets wat nog mist in onze implementatie.

Er is een PR die alle berichten een PacketId geeft, zodat er een brug gevormd kan worden tussen de berichten op de plek waar ze gequeued worden en de plek waar ze verstuurd zijn. Deze implementatie werkte alleen met manual polling en werd om die reden afgewezen. Poging twee staat al een tijdje stil. Voor statime is er een oplossing in deze richting nodig.

[diondokter]

The mentioned PR has been merged and we shouldn't have to do any work on smoltcp to make it work for us