Tables added through Views query alteration should use a relationship

Problem/Motivation

This is a follow-up to #3549548-10: Views relationships to the same entity type are missing deleted check, allowing deleted content to show in views listings → .

One of our Views based on a custom entity referencing nodes via an Entity Reference Revision field is crashing as the table added in query alteration is unable to find a path back to the base table.

Steps to reproduce

(Sorry these are rough, don't have time to confirm detailed steps.)

1. Have two entity types, ensure the second one is revisionable.
2. Have the first entity reference another revisionable entity via an Entity Reference Revision field.
3. Build a View of the first entity type.
4. Add a relationship to the second entity type via the ERR field.
5. Add a field using that relationship, like title.
6. Create some content with both entity types, ensuring to reference older revisions of the second type.
7. Run the View and expect to see all the content.
8. Soft-delete some of the referenced entities (creates new revisions)
9. Run the View again and expect the soft deleted ones are not in the output.

Proposed resolution

@amateescu and I spent some time debugging this and discovered it works correctly if we explicitly speficy the processed table's alias as the relationship id when adding the new data table. When feching the data table we also need to take check if there actually is a data table for the entity type and otherwise default to the base table.

This made sense to us because we need to add the "deleted" condition within the "scope" of the entity field's joins, and it's not possible for Views to simply figure that out on its own without us explicitly telling it that we do indeed want it to add on to a specific alias/relationship path.

Remaining tasks

Increase test coverage for this. Will do that in later issues.

User interface changes

None

API changes

None

Data model changes

None