Generate enum-typed setters and constructors for signals with value descriptions

[felixvanoost]

• Updates the generated new() constructors and set_<signal>() setters to accept enums for signals that have an associated enum type (value description in the DBC).
• Generates additional set_<signal>_raw() setters for signals that have an associated enum type, which matches the existing behaviour of set_<signal> before these changes. This now makes the API for the getters and setters symmetrical.
• Cleans up the formatting of some generated getter/setter function comments for readability and consistency.

This is a breaking change for DBCs that have signals with value descriptions, but should make these signals much cleaner to handle. The best approach is to directly pass the enum-typed signals into set_<signal>, but you can retain the existing behaviour by simply using set_<signal>_raw instead.

This PR should be stacked on top of #176.

[codecov]

Codecov Report

❌ Patch coverage is 84.26966% with 14 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/lib.rs	84.26%	14 Missing ⚠️

📢 Thoughts on this report? Let us know!

[trnila]

(would prefer full name param_type or signal_type?)

[trnila]

I think signal bits extracted from received/sent bytes are called raw. This raw value is then converted into physical value (e.g. bits into floating voltage 5.02V) by scaling and adding offset.

This function is actually converting physical value into its raw value and we dont have any function to set the real raw bits. Not sure if there are usecases, but it might be little confusing? Not sure if set_value1_logical wouldn't be better?

The non-suffix type-safe set_value1 would pass logical value into set_value1_logical, that applies linear transformation and then stores the raw bits into the buffer.