[thenetworkgrinch]

Every vendor now reads a device's canbus the same way, so the JSON configuration no longer depends on which vendor a device comes from.

canbus	Bus
"" (or missing)	can_s0 (bus 0)
"0" to "4"	can_s0 to can_s4, so "1" is can_s1
"5" to "24"	Motioncore can_d0 to can_d19, following WPILib's CANPort
anything else	passed to the vendor, such as a CANivore's name for CTRE devices

• New swervelib.core.parser.CANBuses does the conversion, and each vendor turns the result into its own bus type: Phoenix 6 CANBus(CANPort), REV CANPort, ThriftyLib's bus number (CANPort.value), and ReduxLib's Canandgyro/Canandmag(int, CANPort) constructors.
• REV and Thrifty Bot devices reject anything other than a bus number, with an error that explains the bus numbers. Bus numbers that do not exist ("25") also give a clear error.

Behavior changes

• CTRE devices with an empty canbus are now on can_s0, like every other vendor. Before, Phoenix 6 put them on its Systemcore default, can_s2. Configurations whose CTRE devices are on can_s2 need "canbus": "2".
• Redux devices take bus numbers. ReduxLib bus strings such as "socketcan:can_s1" still work, since they are passed through.
• REV devices no longer take port names such as "CAN_S1"; use "1".

The test schemas' canbus descriptions and the DeviceJson.canbus docs describe the new values. The config generator's schema may need the same update.

Not meant to be released yet.

Test plan

• New CANBusesTest (17 tests): empty and missing canbus, bus numbers 0 to 24, unknown bus numbers, vendor specific names, and the REV/Thrifty error.
• Full YAGSL test suite: 238 tests pass, including the parser tests that build CTRE, REV, Thrifty and Redux devices.
• verifyVendordepJsons passes.