Addressing #14440 and the design doc, this PR introduces EntityClassification computed artifact that classifies all 1st and 3rd party entities (recognized by third-party-web and unrecognized). The classification is exposed in LHR as a top-level property LHR.entities. By and large, this achieves a few important things:

1. Switches third-party filtering logic on the reporting side from origin string comparison to proper entity comparison. Now moved to report: use entity classification to filter third-parties #14697.
2. Lays down the necessary groundwork for grouping and aggregating reports by entities (report: group third-party entities #14655). This will also support filtering reports by entities, in future. Now moved to report: use entity classification to filter third-parties #14697.
3. Partially addresses Expand third-party classification to include unrecognized entities #14440 (Everything minus "Closing the loop", which requires additional work to reduce the amount of user-generated reports, through automation).
4. Implements a computed artifact that audits can use to resolve urls -> entities during audit time (optionally marking audit result items with their entities during audit time). Audits that don't resolve entities during audit, but feature a url in any form (url, or source-location, etc.) will be resolved during prepareReportResult phase.

This is an alternate implementation to #14614, based off discussion on the PR. This will attempt to do the same outcome as the original PR, but without classifying entities during most of the audits.

I've completed the checked items on this branch:

• Branch off new_audit: entity-classification #14614, to continue receiving PR-feedback changes I make there to entity-classification parts.
• Reverse-patched all changes except entity-classification audit itself (and tests), and the the audits that require to find 1st/3rd parties during audit (see below for a list).
• Brought back the LUTs (Look Up Tables), so the report side could convert URL origins and entity names to URLs without too many iterations over entities. Their use is probably better justified in this branch.
• Implemented a _computeTableItemEntities function in DetailsRenderer that (Now moved to report: use entity classification to filter third-parties #14697),
  • looks for TableColumnHeading.valueType === 'url' and picks up the key to identify a URL to lookup entity for. This should cover all audits that include a url in any column (checks only the first level items).
  • skip any audit that has already marked item.entity during audit.
  • deal with audits that have differences in output and requires special handling.
    • source-location in item.source level.
      • no-unload-listeners
      • geolocation-on-start
      • no-document-write
      • notification-on-start
      • uses-passive-event-listeners
      • deprecations
    • origin corresponds to url but marked as valueType: text
      • network-rtt
        • Skipped handling this as this is a hidden audit.
      • network-server-latency
        • Skipped handling this as this is a hidden audit.

Additional targets based on the meeting discussion:

• Make entity-classification available as an LHR level property, and remove it from being an audit.
  • Retain ComputedEntityClassification for any audit that would like to classify entities during audit.
• Drop item.entity query-ability from LHR JSON.
• Move entity resolution to prepareReportResult (Now moved to report: use entity classification to filter third-parties #14697).
• Rename lhr.entityClassification to lhr.entities and lhr.entities.list.

Audits that make use of ComputedEntityClassification to resolve 1p vs. 3p during audit time:

The following audits previously assumed that all unrecognized third-parties are first-parties.

• valid-sourcemaps
• third-party-summary
• third-party-facades (Marks entities on items during audit)
• legacy-javascript

Comparison to 14614: entity-based-3p...entity-based-3p-reportonly

I've tried to document all the audit results that deal with a URL and could use entity classification, but have differences in their output format, and requires special handling, in this document. It might not be exhaustive yet, but we could use it to collect them and discuss how to handle those differences.