Add --kind and --level arguments for granular control of results reporting

[michaelcfanning]

Implementation notes:

• Follow the same pattern for enum arguments set by OptionallyEmittedData
• Defaults follow current reporting behavior --kind Fail and --level Error;Warning
• Currently, the SDK provides all reporting not matching the criteria in point 2 in the case when the --verbose flag is passed. We should consider deprecating --verbose entirely, as we also have the new --traces mechanism to control arbitrary verbose reporting. Something to keep in mind as we review this functionality globally.
• We need to locate the best place to insert the filtering. The open question is whether we should disable skimmers based on these settings (because we determine they can never fire) or if we allow them to function then filter immediately before logging. Let's start with the latter approach as a default (I'm open to a contrary view though if you build one)
• Let's start a new 1.8 versioning line for this significant change in tool behavior.

@eddynaka @jameswinkler, FYI

[michaelcfanning]

For completeness, I will mention that when building this, we should at least consider the possibility we want an even more granular, per-rule mechanism to control reporting behavior.

For example:

-level Error;BadRuleId.Note

might do something like remap BadRuleId's output into a Note (which could be disabled). we should also consider whether this argument could contain a value like 'Disabled' which doesn't literally existing on the SARIF Level type. we could do this because we'll have a string [] representation we can process because constructing the SARIF types. On encountering a Disabled value, we would proactively add this id to the disabled skimmers set.

This would provide a super easy way for people to opt out of a poorly behaving check (one that's crashing in general code paths for example).