feat: Enable scanning of chromium content

[DaveTryon]

Details

In #951, we intentionally excluded all elements inside a Chromium document from scan results. This makes sense for most developers, since the conversion from HTML to UIA is convoluted and outside the control of the HTML developer. However, the Edge team relies on this functionality to help improve their HTML-to-UIA conversion code. This PR defaults to excluding the elements inside a Chromium document, but adds a way to request that scan results include elements within a Chromium document. This option is exposed in 3 places:

1. In the Automation layer
2. In the CLI
3. In the SelectAction class (for future use from Accessibility Insights for Windows)

Motivation

Requested by the Edge team

Results

Comparison.zip contains Default.a11ytest and WithChromiumContent.a11ytest, which were captured by running the CLI on the same instance of Edge. The rule comparison is as follows:

Message	Default Count	WithChromiumContent count
An on-screen element must not have a null BoundingRectangle property	5	5
Chromium components should be scanned with an web-based scanner	2	2
The Name must not include the same text as the LocalizedControlType	2	2
The Name property must not include the element's control type	2	2
An element must not have the same Name and LocalizedControlType as its parent	0	4
An element of the given ControlType must support the Text pattern	0	1

The elements that are unique to the WithChromiumContent file are all within the Chromium document

Screenshots

Case	Snapshot (click to enlarge)	Results (click to enlarge)
Default
WithChromiumContent
Delta

Context

• The Actions project didn't previously reference the Rules project directly, so the plumbing may be non-ideal. If we were to use the existing dependencies, Actions would call into Desktop, which would call into RuleSelection, which would call into Rules. We can add the 2 missing layers if we think there's value there.
• The flag to enable Chromium content is basically global. This will work as expected in the CLI, in AI-Win, and in AccChecker. It will fail if someone creates a scenario where concurrent scans want to have different Chromium behavior. I've taken a YAGNI approach for now, and we can always make it more complex at a future time, should that prove necessary.

Pull request checklist

• [n/a] Addresses an existing issue:

[codecov-commenter]

Codecov Report

Merging #967 (f8d951f) into main (4fc19c3) will increase coverage by 1.18%.
Report is 345 commits behind head on main.
The diff coverage is 79.33%.

❗ Current head f8d951f differs from pull request most recent head d58bcc4. Consider uploading reports for the commit d58bcc4 to get more accurate results

@@            Coverage Diff             @@
##             main     #967      +/-   ##
==========================================
+ Coverage   73.70%   74.88%   +1.18%     
==========================================
  Files         398      424      +26     
  Lines       12046    13117    +1071     
==========================================
+ Hits         8878     9823     +945     
- Misses       3168     3294     +126     

Files Changed	Coverage Δ
src/Actions/Actions/ControlPatternAction.cs	0.00% <0.00%> (ø)
src/Actions/Actions/CustomUIAAction.cs	0.00% <0.00%> (ø)
src/Actions/Actions/ListenAction.cs	0.00% <0.00%> (ø)
src/Actions/Actions/PrivacyExtensions.cs	100.00% <ø> (ø)
src/Actions/Actions/SetDataAction.cs	0.00% <0.00%> (ø)
...rc/Actions/Attributes/InteractionLevelAttribute.cs	0.00% <0.00%> (ø)
src/Actions/Misc/ExtensionMethods.cs	7.46% <0.00%> (-31.60%)	⬇️
src/Actions/Resources/ErrorMessages.Designer.cs	0.00% <ø> (-55.56%)	⬇️
src/Automation/AxeWindowsAutomationException.cs	33.33% <ø> (-33.34%)	⬇️
src/Automation/Data/OutputFile.cs	88.88% <ø> (ø)
... and 143 more

... and 243 files with indirect coverage changes