Added define's for CAN message ID's + increased specialization of enu…

[warrickw]

I've made 4 changes in my repo:

• Tweaked the parser val and val_item by moving where a space is. It wasn't parsing my values because it was expecting a space after each val_item, which the last item won't have. I've moved it to expect a space before each item.
• Added generation of #define's for the CAN ID's of the messages
• Updated the enum value generation to generate the message name
• Updated the encode/decode function generation to include the message name

Considering the following value list - there's two signals called state, but for different message ID's (1 and 2):

VAL_ 1 state 0 "Inactive" 1 "Active";
VAL_ 2 state 3 "OFF" 4 "ON";

Generated enum definition before change (won't compile):

After (now generated after corresponding message definition):

(After, but without the -N flag to remove the message ID's)

Q:
I'm unsure what effect my proposed changes have to the global VAL_TABLE_ section in a dbc file. I suspect they won't get generated after these changes, because I'm only generating enums for vals that are associated with a message.

[howerj]

I'll take a look when I can (maybe this weekend?), thanks for the detailed pull request though. A quick glance suggests it is sensible, although I would be worried it could break existing code that use the current mechanism as this would be a big breaking change.

[howerj]

I think I will have to hide this behind an options flag (or the old behaviour) so as to not break existing code. I'll merge this on to a branch and then work on that, I think.