Unify bit timings with separate class for CAN FD

[zariiii9003]

This is a continuation of #614 and #615. I would like to hear your opinions before i waste my time on writing tests and docs.

I made the following changes:

• Create a separate class for CANFD. In my opinion the bit timing requirements for CAN2.0 and CANFD are just too different to use the same class for both.
• Validate bit timings in __init__ method
• Add multiple constructors to avoid too many optional parameters. It is now possible to create an instance though BitTiming(**kwargs), BitTiming.from_registers(**kwargs) and BitTiming.from_sample_point(**kwargs)
• The bit timing classes inherit from typing.Mapping. Now the user can call dict(timing) to get a dictionary of the bit timing parameters. This should make it easier to save the parameters to a config file.
• Solve the configuration loading problems of Fix Bus.__new__ for PEAK CAN-FD interfaces #1460

Interface implementations should add a single parameter like timing: Union[BitTiming, BitTimingFd]. It would take precedence over other parameters and provide a simple API for the user. The docstring of the parameter should tell the users which values for f_clock are accepted.

[felixdivo]

Thank you @zariiii9003, the proposal sounds very reasonable! I am honestly not that much of an expert with the bit timing mechanisms, so I'll retreat from this discussion. But at a glance, this looks like a very useful contribution.

[zariiii9003]

@lumagi @bmeisels Could you take a look, too?

[lumagi]

This looks impressive! I will look through the code over the next day or so.

[lumagi]

I added a few comments with things to came to my mind. I can also support with writing further tests if necessary or with doing manual tests of the Peak interface when this PR is merged.

[zariiii9003]

@hardbyte I'll wait for your approval, since this is a quite a big change.

[zariiii9003]

I will merge this in a few days if there are no objections