Clarify expected behavior of adding a missing version to the revision history

[tschmidtb51]

As there was some confusion in #21 (unfortunately caused by a misunderstanding), I try to sketch the expected behavior as a new issue:

• If the current version is not in the revision history (independent from the current release date): throw an error
• The config (and command line) option fix_current_version_not_in_revision_history (feel free to choose a different name) has the default value false. When it is set to true, the converter adds the current version in the revision history if it is missing (independently whether the previous version exists) and adds a warning that the current version was not in the revision history and was added and that this might impact the revision history's integrity.

This requires the following changes:

1. Rename the config option --force-update-revision-history as it is not intuitive. When I read --force-update-revision-history I would expect that this option updates any revision history (independently whether valid before or invalid as e.g. A, B, C) to a valid integer versioning. CSAF uses the terminology of quick-fixes for recommended actions if one of the tests from section 6 fails. That's why I came up with fix_current_version_not_in_revision_history. However, I'm also happy with a --force~ if it conveys that it adds only the current version if it is missing.
2. Rewrite the code https://github.com/csaf-tools/CVRF-CSAF-Converter/blob/3fef14901d0605f54b1ce0c3baf9b056d4d44f88/cvrf2csaf/section_handlers/document_tracking.py#L79-L91

   if fix_current_version_not_in_revision_history is True:
       logging.warning('Forcing update of the revision history and adding the current version. ' 
                           'This may lead to inconsistent history.') 
   else: 
      logging.error('Current version is missing in revision history. ' 
                               'This can be fixed by using --fix_current_version_not_in_revision_history')
     return

   This suggestion tries to point out the intended function and might not fulfill coding standards nor be in the right place...

3. Obviously, the config parsing code and related code has to be adopted.

[cgi1]

Point 1 +3 --> Changes for renaming:

1

2

Point 2

This suggestion tries to point out the intended function and might not fulfill coding standards nor be in the right place...

@tschmidtb51 could we please do a quick explenation on Monday? I am not 100% certain, that we fully understood this.

[cgi1]

Filip knows what to do. :)