Expose a Workflow filter on the personal task lists, with the filter handler that already exists

Fixes #3624942.

The personal task lists had no way to narrow what they show, and the piece needed for it already existed and was used nowhere.

orchestra_views ships WorkflowFilter (#[ViewsFilter("orchestra_workflow")]), an InOperator that offers workflow labels rather than machine names and scopes the option list to the acting tenant deliberately — "on a multi-tenant site the labels of another tenant's workflows are not this operator's to read". OrchestraViewsHooks wires it to orchestra_instance.definition under the title Workflow. An exact search for that filter id across the shipped views returned nothing.

So this is config only:

• The filter goes on default (inherited by the open-tasks page) and on page_2, the history tab, which has its own filters and would otherwise narrow differently.
• No new join: the view already declares a required instance relationship, so the process instance is on every row today.
• No new dependency to install: orchestra_inbox_views already depends on orchestra_views.
• The exposed form already renders for the two sorts, so the control joins a block that exists.

Verified on a site

One task, from the request_validation workflow:

filter offers 21 workflows, by human label ("Demo: approval (user task)", …)
filtered to request_validation  -> 1 row   (kept)
filtered to demo_parallel       -> 0 rows  (excluded)

MyTasksViewTest and TenantTasksViewTest both pass.

One note for review

The view now declares orchestra_views, since it uses that module's plugin directly. Saving the view in Drupal also recalculates orchestra and orchestra_inbox_views into that list and drops views — configuration does not depend on the module defining its own entity type. That drift predates this change, and the file's own comment explains the single enforced dependency as deliberate, so I left it rather than rewrite it here. Worth a separate look if you want the shipped file to match what a save produces.