[Cyphal/CAN] Update the docs on the backlog queue for the STM32 driver

[pavel-kirienko]

This is no longer valid because libcanard now supports independent queue per interface:

platform_specific_components/stm32/libcanard/bxcan/src/bxcan.h

Lines 129 to 150 in de15924

	/// Redundantly interfaced configurations shall maintain a backlog queue to account for the fact that different
	/// interfaces may be unable to transmit frames simultaneously due to different bus load (in terms of frames per
	/// second). It is assumed that the outgoing frames are kept in a single prioritized transmission queue, which has
	/// to be split into two queues to support different bus loads per interface. One approach is to implement naive
	/// copying into two queues, but this approach leads to increased memory utilization. A more conservative approach
	/// is to keep a unified queue keeping the outgoing frames for both interfaces, and a single backlog queue keeping
	/// the frames for the interface that is lagging behind. This way, no memory overutilization will occur. One backlog
	/// queue is sufficient since the faster interface will be fed directly from the shared queue. Graphically:
	///
	/// [FRAME SOURCE] ---> [ SHARED QUEUE ] --------------------------> [FAST INTERFACE]
	/// |
	/// ---> [BACKLOG QUEUE] ---> [SLOW INTERFACE]
	///
	/// Where "FRAME SOURCE" is typically a Cyphal/CAN implementation library (like Libcanard), and "SHARED QUEUE" is the
	/// main prioritized transmission queue (like the one maintained by Libcanard). Which interface is the FAST one and
	/// which one is the SLOW one cannot be known in advance, obviously. They may change roles depending on the bus load
	/// conditions. The backlog queue may be implemented as a naive static array that is scanned whenever a frame is
	/// inserted or extracted; the linear time complexity may be acceptable because typically the backlog queue is small.
	///
	/// One should note that the need for maintaining a separate backlog queue arises out of the limitations of the bxCAN
	/// macrocell. Certain advanced CAN controllers are equipped with a sufficiently deep hardware transmission queue
	/// that relieves the application from manual queue management.

Also the last part about the availability of deep hardware queues is rarely true; see this for details: https://forum.opencyphal.org/t/uavcan-can-tx-buffer-management-in-can-fd-controllers/1215