Review of project and release paths on the frontend and admin, add project filter

Problem

• Drupal 7 addressed projects by machine name everywhere: translate/projects/drupal, its releases at translate/projects/drupal/releases and a release at translate/projects/drupal/releases/42829, and the administration pages under admin/l10n_server. 3.0.x generates entity ids in project paths, front end and back end, serves releases at /release/42829 and the administration under /admin/localization and /admin/config, while a few hand-written links still use the machine name and lead to a 404. Every link to a project or release on localize.drupal.org changes with the migration.
• The project administration list has no way to find a project among thousands.
• The releases page of a project shows a generic page title and repeats the project name in a heading inside the page. Its string, line, file and warning counts are plain numbers, the lists behind them cannot be limited to one release.
• The parser warnings are "errors" in the administration menu, the tab, the entity labels and the list. Drupal 7 called them source code warnings, which is what they are.

Proposed resolution

• Project paths carry the machine name, like Drupal 7: the entity generates its route parameter from the machine name, a parameter converter loads projects from it (ids still load, for old links) and a route subscriber lifts the numeric requirement the entity route provider puts on the parameter. The links written by hand go through the entity.
• Release pages sit under their project as on Drupal 7, translate/projects/qtc/releases/42829, with edit and delete next to it, and a new release is added at translate/projects/qtc/releases/add with the project fixed by the path. The "Add release" link appears on the releases page of a project taking uploads, instead of a generic action on the list of all releases.
• Administration paths sit under /admin/l10n_server, like Drupal 7: the overview and its sections, every list, the connectors, the packager and its lists, the community settings, start over and clean up.
• The project administration list gets a filter matching any part of the name or the machine name, in the box the Views exposed filters use on the people list, with Filter and Reset buttons.
• The releases page of a project takes "Project releases" as its page title, and the counts of strings, lines, files and warnings link to those lists limited to the release. The four lists take a release parameter, say which release they show and link back to everything. Strings reach a release through their lines.
• The parser warnings are warnings in every label, with the list at /admin/localization/warnings. Machine names stay.

Tests

Drupal 7 tests already assert the machine name paths, they are the specification. On 3.0.x the project list test checks the machine name links and the filter, the languages and projects test checks the address of a project page, the start over test uses the new paths, and L10nAdminListsTest covers the releases page title, the count links and the four lists limited to one release. The functional test fixture now stores line, file and warning counts on releases as the parser does.

LLM disclosure

LLM was used to find, diagnose explain and fix this issue. With human review.