FEATURE: Simplify DBC decoding by persisting DBC files

[MatinF]

Today, loading an MF4 file in asammdf and DBC decoding it involves the following steps:

1. Open an MF4 file
2. Go to the Bus Logging tab
3. Browse to and load the DBC file(s)
4. Click 'Extract Bus Signals'

Having collected quite a bit of feedback across hundreds of CANedge + asammdf users, the above steps comprise one of the primary 'time consumers' in working with their data. 90% of these users load the same DBC files every time.

An alternative/supplement to the above could be a 'DBC file manager'. I believe you may already have done some work on this, so below is just my two cents on how it could be implemented:

1. The manager could be placed under Managers/DBC file manager
2. Within it, you would have a similar view as in the Bus Logging tab for DBC files:
3. The user would be able to optionally use the manager to load their 'frequently used' DBC files, almost like 'bookmarks'
4. When the user has loaded a list of DBC files in the manager, these are automatically populated in the Bus Logging tab version of the same view. The user can then delete them from that view if they e.g. temporarily need to use another DBC file - or they can keep them as-is and immediately hit 'Extract Bus Signals', thus saving the effort of loading the DBC files

Importantly, I do not think that asammdf should serve as a DBC file editor. Plenty of other options exist already for this like our online DBC editor, Kvaser's DBC editor and Vector's DBC editor CANDB++. Tools like SavvyCAN that have attempted to create DBC editors have not done so with great success in my opinion and I strongly recommend keeping that out of asammdf as well.

[danielhrisca]

@MatinF please have a try with the development branch code

[MatinF]

This seems to work great Daniel, I think this is a nice way of implementing it. Users that don't feel like using this functionality can continue as-is, while users that frequently deploy the same DBC files can load them once and even configure their setup with e.g. Channel specific decoding.

I think this would be a nice addition for the next release - closing this issue as I think this implementation fully resolves this.