A new redirect fails to save when a redirect trashed in the same workspace has the same source

Problem/Motivation

Trashing a redirect sets its hash to deleted-<uuid>, so a new redirect can use the same source. Inside a workspace that change is only in the workspace revision. The base table keeps the old hash until the workspace is published, and the hash has a unique key there.

A new redirect from the same source in that workspace passes validation, because Trash hides the trashed redirect from the RedirectUniqueHash check. Saving it then fails:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '...' for key 'redirect.hash'

This needs redirects to be workspace-supported (#3313540: Convert the Redirect entity type to revisionable), and the unique hash check to read the base table (#3629356: Changing a path alias fails with a duplicate hash error when a disabled redirect exists for the old alias).

Steps to reproduce

1. In Live, add a redirect from old-path.
2. Switch to a workspace and delete that redirect, so it goes to the trash.
3. In the same workspace, add a new redirect from old-path.

Proposed resolution

Add a TrashedRedirectSource constraint to redirects. It reads the hash from the base table, and when the matching redirect is trashed in the active workspace, the form says The source path old-path is used by a redirect in the trash, with a link to the restore form for users who can restore it. The Redirect module's validator is not changed. Nothing changes in Live, where a trashed redirect already has a deleted-[uuid] hash in the base table.

Remaining tasks

Review.