Don't treat signals as floats if factor is a whole number

[hulthe]

Before this change, any signal with offset != 0.0 and factor != 1.0 would be represented as a float in the generated Rust.

This change checks if factor and offset are integers. If so, the generated rust type is set to the smallest integer type that fits the value (accounting for offset and factor).

So a signal like this (8 bits, factor=2, offset=13) would be a u16:

  SG_ MySignal : 0|8@1+ (2,13) [1|256] "" Vector__XXX

Unresolved Questions

• How to handle signals that, when accounting for offset and factor, exceed the capacity of u64s?
  Currently they willl always be truncated to fit in a u64
• How to handle invalid values provided to set_<signal> methods.
  I.e., what should happen if you provide 0 to a signed integer signal with offset 1.

[killercup]

How to handle signals that, when accounting for offset and factor, exceed the capacity of u64s?
Currently they willl always be truncated to fit in a u64

Why not fall back to f64? Might produce a warning if desired.

[killercup]

nice! lgtm with ci fixed/clippy appeased

[killercup]

memo to self: review those :D

[hulthe]

Did some tests with overflowing u64s, and it looks like dbc-codegen doesn't handle those well for other reasons too x)

I'm thinking we leave it. Would like to get this merged.