docs: CARS.md 2.1

[jyoung8607]

Design goals

• Preserve openpilot CARS.md location/behavior, supported cars only
• Start generating a new, separate CARS.md in opendbc
• opendbc's CARS.md will have less detail, but include many more cars
• don't break the website or the shop

Preview

• opendbc_repo/docs/CARS.md
• Documenting cars that aren't upstream: extra_cars.py
• Annotating upstream cars in dashcam: ford/values.py

To-do

• "atypical install" or something instead of "legacy", will include SecOC

[adeebshihadeh]

The classes don't feel quite right to me, but seems fine to start with. The infra and presentation look great.

[sshane]

Would a link to the under review PR be a good idea?

[jyoung8607]

I wrote the support link stuff with the idea we could override the link target, for any entry, to something outside the doc. A comma PR, a fork repo, something at docs.comma.ai, whatever. Or, we can make it a footnote style link, or whatever seems reasonable as we go.

Unrelated note, will hook up CI tests tomorrow AM to make sure new CARS.md is always up to date, same as openpilot.

[sshane]

@jyoung8607 is there any reason we can't merge these car infos into their respetive brands? this adds some extra complexity and would be nice if we didn't need special handing in docs.py

[jyoung8607]

Adeeb wanted to eventually document ALL cars. We don't have brand directories for, say, BMW or Mercedes.

Additionally, a lot of the non-support reasons were shared between makes and seemed to make sense to collect together. For example, all cars unsupported due to Flexray could use a common Flexray doc platform, all cars with (unmitigated) SecOC could use one SecOC doc platform, etc.

For those brands where we do have some existing support, a case could be made to move those definitions to the brand. I'd have to see how it looks and if code changes are needed.