Confidence Indicator of Detection Methods

From @jonthysell in prior PR comment:

If this really is a runtime check (and not a static check as per my earlier comment) I would prefer if we listed them by highest to least confidence (I can update the template to reflect this):

1. (Maybe never attainable) We unambiguously detect part of a framework being used in the running app (i.e. a control rendered at runtime)
2. We see markers of a framework being used (i.e., class name / UIA identifiers) that could technically be spoofed or mistaken because there's no namespace enforcement
3. We detect that the framework's module was loaded by the process (process could load a module transitively that doesn't actually get used by the app, also naming issues)
4. We detect a (transitive) dependency via a package manifest (again, could be marked as a dependency but not actually used by the app)

This ordering should also be reflected in the detector as closely possible.

We should probably have this definition "baked in" vs. determined by the defined order within a detector (i.e. we don't want to try and have to coordinate between detector authors how to order specific checks within their detector).

We should define what the above criteria is and how various checks fall within their ranks. Then, since we run all checks, we can order by the confidence level and include that indicator as part of the output/results?

No files, tests, or entry points are named. Start by reviewing how detectors order checks and how detection results are represented; then define the four confidence levels, map checks to them, and determine how the confidence indicator should appear in the output. Done means the ranking is consistent across detectors and results expose the confidence level.