ADMIN_BASE_TABLES turns every taxonomy term and user view into an admin view, producing ANON_ACCESS_ADMIN errors on frontend blocks such as who_s_new

Problem/Motivation

isAdminView() in modules/audit_views/src/Plugin/AuditAnalyzer/ViewsAnalyzer.php returns TRUE for any view whose base table is in ADMIN_BASE_TABLES = ['users_field_data', 'node_field_revision', 'watchdog', 'file_managed', 'taxonomy_term_field_data'], whatever the display is.

Watchdog entries, file usage and node revisions really are administration data, but taxonomy terms and users are regular frontend content: category and tag listings, location blocks, author pages, and core's own who_s_new and who_s_online blocks. Every display of such a view that anonymous users can see is reported as an ANON_ACCESS_ADMIN error ("Administration view is accessible by anonymous users"), which drives the anonymous_access factor towards 0 on sites that have nothing wrong.

On a real site, after #3630438 and #3630439, the only ANON_ACCESS_ADMIN errors left in the views report were the core who_s_new block (users_field_data, "access content"). Without the term and user tables in the list the report has no ANON_ACCESS_ADMIN errors, the anonymous_access factor goes from 75 to 100 and the views score from 84 to 87.

The real administration listings of users and terms are still detected by the other signals: the user_admin_people view id and any page display under admin/ (both fixed in the two issues above).

The unit test testIsAdminViewByBaseTable() asserts users_field_data => TRUE, so it encodes the false positive.

Steps to reproduce

1. Standard install, anonymous users have "access content".
2. Place the core "Who's new" block (who_s_new view, block_1 display).
3. Run drush audit:run views --format=json.
4. who_s_new block_1 is reported as an ANON_ACCESS_ADMIN error.

Proposed resolution

Remove users_field_data and taxonomy_term_field_data from ADMIN_BASE_TABLES and document why in the constant. Keep watchdog, file_managed and node_field_revision, which only administration views list. A user or term view is then an admin view only when it has another signal (an admin view id or an admin/ path).

Evaluating "admin" per display instead of per view, so that non-routable displays (entity_reference, embed, attachment...) never inherit it, is covered by a separate issue about non-routable displays.

Remaining tasks

- Update ADMIN_BASE_TABLES.
- Turn testIsAdminViewByBaseTable() into a data provider: watchdog, file_managed and node_field_revision => TRUE; taxonomy_term_field_data and users_field_data without an admin path => FALSE; users_field_data with an admin/ path => TRUE.

User interface changes

Frontend term and user views are shown with the frontend tag and no longer produce ANON_ACCESS_ADMIN errors in the Views audit report.

API changes

None.

Data model changes

None.