feat: add support for multiple CAN buses

[t-bre]

Description

The current implementation works for one CAN bus, but we have two (one for critical systems and one for sensors/non-critical stuff). We will need to extend the system to have a second RTCAN instance, and a second CAN database (from the can-defs repo, which will also need some changes).

Additional Notes

• One possible way to do this would be to have a second instance of RTCAN and a second unpacking thread. This way, the implementation doesn't have to change much other than providing each unpacking thread with a different database.
• This will require a new way of defining PDU IDs. If we have two CAN databases (one for each bus), using the ID in the look-up table as we are now will result in two PDUs with the same ID. We will need a way of including the PDU identifier in the handlers table.

[rureverek]

@t-bre Now, when we can add custom dbc values, shall we add bool variable that tells which CAN message belong to CAN-S or CAN-C bus?

[t-bre]

I think we will have separate databases and handler look up tables for each CAN bus. The problem with having something like you're suggesting is that if two messages on different buses have the same ID, the DBC can't represent that (or at least the software will complain). I'm looking into whether we will need multiple DBC files, or just one. For now, let's just focus on the CAN-C bus and getting that working.