Branch coverage 100%

[amusingimpala75]

I noticed the branch coverage bounty about two weeks ago, and not seeing any work on it listed in a few months I figured I'd give it a go.

Completes #2557 (and I can actually say that if you check out the branch and run the tests you will in fact achieve 100% on the report, unlike some of the AI PRs). I developed this on an M1 MacBook Air, I don't know if that might cause any regressions in coverage.

Notes:

• I disabled the branch checks for the SAFETY_(MIN|MAX|CLAMP|ABS) as I felt that those are sufficiently obvious that we don't need to check for them and it would be a ton of needless checks that I didn't want to bother with.
• I added a couple extra setters/getters for properties, although I wasn't sure if that's okay so they're named with test at the beginning. I'll remove the prefixes on the names if it is acceptable to keep them.
• I can rebase on top of master but I wanted to keep some amount of history of working on it chronologically rather than having all the times squashed to the same minute
• I would not be surprised if some of the changes I made are asked to be refined. For example, if there was a bus and address check but the address was only registered for a single bus I removed the bus check as it was unnecessary, but I could see that being not desired if there is a decent chance of modification later. I dunno
• AI assistance was used in the exploration of the codebase, but was limited for the code writing; I think I used it in one case which I noted in that corresponding commit.
• I recognize the number of commits may not be ideal; again, I found it helpful for organising while coding but can squash it before merging.
• I wrote the Tesla modifications to use a switch because I felt that was the best way to do it (chains of comparing one variable to various values). If that is considered acceptable I would like to suggest re-writing some sections to use switch statements.

I am of course ready to go through the back-and-forth of code review, so if there are any changes that should be made for the completion of the PR/bounty please let me know!

[github-actions]

Thanks for contributing to opendbc! In order for us to review your PR as quickly as possible, check the following:

• Convert your PR to a draft unless it's ready to review
• Read the contributing docs
• Before marking as "ready for review", ensure:
  • the goal is clearly stated in the description
  • all the tests are passing
  • include a route or your device' dongle ID if relevant

[amusingimpala75]

Huh, it looks like my usage of llvm-cov instead of gc-cov (or whatever its called) is causing discrepancies, even though thats the current default here

[amusingimpala75]

Nope, the issue is actually the machine architecture, I guess arm simply has better machine code

[amusingimpala75]

I got to use WSL to get the rest of it over the finish line lol. I'm gonna mark this as ready for review because although the last test cancelled it was just because it timed out for the car diff job to finish before it would comment it here (and the dependency action has succeeded now but I can't figure out how to have it re-run the cancelled check like I can when a commit check fails).