Validation report: Show the list of notices that could not have been checked because of a parsing problem

[isabelle-dr]

⚠️ Need to do #1537 and #1536 before this issue.

Context about the issue

When there is a parsing problem, some of the validators don't run validators don't run and a portion of the notices can't be checked.
This creates confusion for the users (see #1167).
We want to add a new section in the validation report that gives the user the list of notices that could not have been checked because of a parsing problem.

The list of notices referenced should only include validators that were not run because of a parsing problem, -not- because a component was missing from the dataset. (E.g duplicate_fare_media should not be included in the list of notices if there is no fares data, or pathway_to_wrong_location_type should not be included to the list of notices if there is no pathway data).

What this issue is for

This issue is for adding the section in the validation report that gives the user a list of notices that could not have been checked because of a parsing problem. This informs the user that these notices might be present in the data.

Not doing in this issue

Optimizing the list of validators that didn't run because of a parsing problem so that we don't stop validators from running when they actually can. We have an issue open for this #1484.

[isabelle-dr]

Related to #1484
Might be related: #1089

[briandonahue]

@isabelle-dr would this list be shown on the HTML report, and/or do you want it included in the JSON report?

[isabelle-dr]

@briandonahue I am not sure. I see that when we added the Metadata (or Summary) in the HTML report, we didn't add it to the JSON report. Why did we decide not to, in this case?

I thought it would be more straightforward to have all the results in the JSON report and then use this to display the HTML page, but I may be over-simplifying things.
I also think from a user perspective, it's nice to have parity so that people that use the JSON report get the additional value as well, although we should be careful with breaking changes.

[briandonahue]

@isabelle-dr My understanding (perhaps incorrect) was that the metadata section was only requested for the HTML report. The two are generated separately currently. I don't necessarily think it's a bad idea to use the JSON as the source for the HTML report, but it would require significant changes.

[briandonahue]

Initial work in #1496 is gathering the list of skipped validators due to parsing errors, but the further details required to collect the resulting skipped rules/notices is not readily available and will require more discussion and effort to allow those to be derived from the skipped validators. Additionally we may want to capture and report contextual information on why certain rules could not be validated, such as which files could not be parsed, and which rules could not be validated as a result.