[Spike] Investigate feasibility and possible architecture of QSR on Traveo II

Traveo II is an MCU platform for Automotive, which has several MCUs variants designed for graphics applications, especially Instrument Clusters and HUDs.

An overview of the hardware features of these MCUs can be found at https://qtcompany.sharepoint.com/:p:/s/MCUSoftwareTools2/EXQK9IyfPZlMu32gmTx_Jx8BvP7PeOWUZti6KSerCTxUpw?e=AsepZ2 

Qt for MCUs supports this platform, but only for non-safe graphical content.
Because the hardware has a Signature Unit for graphical safety checking, QSR could be used in combination with Qt for MCUs.

Documentation for FuSa on this platform and for the Signature Unit Driver can be found at https://qtcompany.sharepoint.com/:f:/s/MCUSoftwareTools2/EthjPT19ovFEuTsmEMa0zs0BMdHVBkLoJZdavkZCy4i6Gg?e=kDbdsO 

The goal of this task is to investigate the feasibility of adapting QSR to this platform, and evaluate what architecture would be adequate:

• Can the monitoring feature of QSR be used on Traveo II, and how?
• How can it be combined with Qt for MCUs? 
  • Can QSR Monitoring check the rendering of QUL?
  • What would be needed in QUL to enable this feature? (API, tooling, etc.)
  • Does the QUL application need to run on a separate core than the safety monitoring?
  • Does it make sense to use the QSR Rendering engine in combination with QUL?
• Is there any identified risk to adapt QSR to Traveo II and use it together with Qt for MCUs?
• System block diagram for architectures using Qt for MCUs and QSR