Refactor Default Report View

[bbertucc]

Problem

The current report view does not display data in a way that testing results actually work.

Refactoring How Messages Are Displayed

Nodes are the most basic elements in test results. Nodes include messages. Messages tell a user when there are violations with rules, which are tested via checks.

By showing a list of messages first, we are not properly contextualizing the information that the user sees. Without proper contextualization, issues like #472 pop up.

One key note: We will need to be able to see the different messages. Accessibility Pros triage issues by looking at messages.

Refactoring How Pages Are Displayed, Removing Tags

Including pages in the default report view is also vital since pages are a basic data source that users add (with #476). Accessibility Pros like to see which pages have the most issues and the density of issues per page. For more on why density is important, see "Should we consider the volume of issues?" here: https://www.levelaccess.com/blog/so-you-want-an-accessibility-score/#:~:text=One%20common%20example%20of%20this%20is%20grading%20“on%20a%20curve”.&text=In%20addition%20to%20the%20average,the%20Web%20are%20quite%20bad.

Tags are not a basic piece of data, but are related to other pieces of data so we probably don't need to include tags on the default report view, instead allowing folks to use tags to filter existing reports.

Displaying Issue Density Over Time

@aardrian reminded us that displaying the issues on all pages over time was not as helpful as displaying the density of issues per page over time. Using this statistic will normalize chart information, allowing us to avoid problems like when you add a bunch of pages and so the number of issues jumps.

[bbertucc]

@azdak displaying nodes on reports is not useful to accessibility pros.

Accessibility pros look at a list of messages and first decide what issues need to be addressed or not. They then drill into the messages and look at nodes and pages to fix issues.

The user experience should mimic an accessibility pro process, not the architecture of axe-core.

I suggest we disregard the note on refactoring the list of messages to show nodes instead of messages. Unless you have a good UX reason that I'm not thinking of?