License detection_log: position and "- not-combined" values are eventually confusing

[pombredanne]

The detection log should be positioned at the bottom not at the top in the JSON/YAML outputs
But the value "not-combined" is puzzling and not obvious. It is further more cofusing when looking this kind of results:

    -   identifier: mit_and_gpl_2_0-75d8c570-6ad2-0cbe-e6b5-432c94d552a9
        license_expression: mit AND gpl-2.0
        count: 1
        detection_log:
            - not-combined
        matches:
            -   score: '100.0'
                start_line: 5
                end_line: 5
                matched_length: 3
                match_coverage: '100.0'
                matcher: 2-aho
                license_expression: mit
                rule_identifier: mit_172.RULE
                rule_url: https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/rules/mit_172.RULE
            -   score: '100.0'
                start_line: 7
                end_line: 7
                matched_length: 2
                match_coverage: '100.0'
                matcher: 2-aho
                license_expression: gpl-2.0
                rule_identifier: gpl-2.0_818.RULE
                rule_url: https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/rules/gpl-2.0_818.RULE

Here two licenses matches have been obviously combined in a single expression in the resulting license detection. Yet this is reported as "not combined"

[pombredanne]

We need to move the log to the bottom.

And let's drop the "not-combined" entirely in the JSON results, it is misleading and we do not care for things that did not happen.

Let's not report the log by default, but only with a new --license-diagnostics option.
Later we should also provide a narrative that explains the "codes" used for the log entries.

Other notes:

• We need to have some other inputs and opinion of the name to use for "count" which is not obvious: @DennisClark @mjherzog help!
• I would like to see inlined the "rule_relevance" attribute as otherwise the match score may be a head scracther

[mjherzog]

@pombredanne What "count" are you referring to?

[pombredanne]

@pombredanne in a license scan we return each of the unique top-level detections:

license_detections:
    -   identifier: gpl_2_0-d7f02717-086e-f71b-962e-b18cc23b1827
        license_expression: gpl-2.0
        count: 1
        detection_log:
            - not-combined
        matches:
            -   score: '100.0'
                start_line: 1
                end_line: 1
                matched_length: 3
                match_coverage: '100.0'
                matcher: 1-hash
                license_expression: gpl-2.0
                rule_identifier: gpl-2.0_52.RULE
                rule_url: https://github.com/nexB/scancode-toolkit/tree/develop/src/licensedcode/data/rules/gpl-2.0_52.RULE

The "count" is the number of occurences of a given license detection instance, the number of times it showed up across all files.

[mjherzog]

It seems that detection_count would be sufficient in this context