card: process that abstracts car interface and CAN

[sshane]

OG controlsd control flow (before card):

• data_sample: receive can and create CS
• update_events: add events from CS
• state_transition: update control state machine
• state_control: run controllers and create CC.actuators
• publish_logs: finalize CC (hudControl, etc.), generate and send can msgs, add actuatorsOutput to CC, and publish all

[sshane]

EXISTING controlsd & card control flow:

• controlsd->data_sample: waiting for carState
• card->state_update: receive can and create CS, gets latest CC
• card->state_publish: publish CS, CP, CO
  • This is incorrect as at this point we haven't updated CO or actuated anything so controlsd will get the doubly previous CO
• controlsd: gets latest CS and 1 frame old CO
• card->controls_update: actuate CC and update CO

[sshane]

NEW controlsd & card control flow:

• controlsd->data_sample: waiting for carState
• card->state_update: receive can and create CS, gets latest CC
• card->controls_update: actuate CC and update CO
• card->state_publish: publish CP, CO, CS
• controlsd: gets latest CS and CO

[sshane]

There is some controlsState diff, that is expected:

• [x] old routes, such as FORD, had CS.events encompass all openpilot alerts rather than just be car events. This leads to duplicate non-car events in onroadEvents until the route is replaced
• [x] carControl and similar fields relying on carState will be delayed by one frame
• [x] valid goes to True earlier - uses log canValid which is already True
• [x] initialized