Create guidelines for the ccsh analyzer

# Feature request

The different ccsh parser/importer/exporter do not all have the same user interface. The positional and named parameters are not always the same. As a user, it would be great if they all worked the same. The JDK has a [JEP 293: Guidelines for JDK Command-Line Tool Options](https://openjdk.org/jeps/293) and I propose that CodeCharta has something similar and every analyzer references it and says if it is compliant, mostly compliant or not. The gitlogparser in particular seems to not follow the patterns.

## Description

Here is just what I propose as a guideline. It is not finished and not complete. The JDK cli guidelines might also be an inspiration.

### Parameters

| Position | Short Name | Long Name | Description |
| ------------- | ------------- |------------- |------------- |
| (1) FILE or FOLDER or URL | | | The thing that it parses or imports |
| | -h | --help | Print the help text. |
| | -o | --output-file | The thing it produces. Prints to the command-line if not supplied. |
| | -e | --exclude | Things to exclude, typically files or folders. |
| | -f | --format | Specifies the input-format for importers and output-format for exporters. |
| | -nc | --not-compressed | Specifies that output file should not be compressed. |

### General rules

* All log messages go to the error log, so standard out can also be piped to a file.

## Acceptance criteria
- An ADR/design document exists that describes this guideline
- Each analyzer references this document (so future analyzer know it exists)
- Each analyzer describes if it follows this document and to what degree

Start with the proposed parameters, general rules, acceptance criteria, and the linked JEP 293. Inventory the ccsh analyzers and their current interfaces, then create the ADR/design document and identify how each analyzer references it and reports compliance.

Written by the indexing model from the issue text.