Add guaranteed delivery of changes for VT client

[GwnDaan]

As discussed in #231, "some calls to send_something in the VT client fail sometimes". This essentially means that it is not guaranteed that sent changes actually arrive at the VT server.

Since most applications will want their changes to be reliable delivered to the VT server, we can (try to) provide an interface for ensuring delivery.

I think a good starting point is to ensure that the message is actually sent on the bus to the VT, but ultimately we should also check the responses from the VT where possible.

[GwnDaan]

Hey @ad3154, I want to pick up this issue. Though I'm curious on your thoughts on how to implement it. I'm considering adding a 'queue' functionality directly inside the current VT client for the failed send_.. commands. So basically instead of calling the CANNetwork.send_can_message function we could call a private function of the VT client that tries to send the message, and if it fails it will queue it for retrying at a later stage (probably inside .update()). I feel like that's fine?

[ad3154]

Yep, I think that's a good approach - we may also want to have some way to disable/bypass it as well which could be nice on platforms with less RAM.