Filter a venue's places by section, subsection and row

Problem

A venue's Places tab lists every place of the hall, fifty at a time, in the order they happen to have been created. The Auditorium holds well over a thousand, so reaching one row of one section means paging through the house and reading ids. There is no way to ask for what you are looking at.

Every other list in the module already has a filter: bookings, slots, orders and managed resources all extend FilterFormBase, a GET filter whose values live in the URL with a chip bar naming what is active. The places list is the one that needs it most and the one that never got it.

It also loses the filter the moment you use it. The per-row Edit and Delete links carry a destination built from the bare collection route, so editing one place from a narrowed list returns to the top of the whole hall, and the browser's Back lands there too.

Proposed resolution

• A VenuePlaceFilterForm extending the same FilterFormBase as the others, filtering on section, subsection and row: the three the list already shows and the three an operator navigates a hall by.
• The options come from the venue's own places, so a row or subsection is offered only where it exists. They are read as distinct values from the base table rather than by loading a thousand entities to find two dozen strings, which is the read PlaceAvailability already makes for its counts.
• The row operations carry the active filter in their destination, so working through one row is not interrupted by every edit.
• The listing is ordered section, then row, then position along the row: the order a hall is read in rather than the order places were created.

FilterFormBase needs one small addition to make this possible: its collection route is assumed to take no parameters, and a venue's places are reached by a route naming the venue. A collectionRouteParameters() hook defaulting to an empty array covers it, and the four existing subclasses are unaffected.

Remaining tasks

• The filter form, the parameters hook on the base, and the narrowing in the controller.
• The destination on the row operations.
• Functional coverage, because a GET filter is only exercised by a real request: the options offered match the venue, section and row narrow together, the subsection narrows alone, a filter matching nothing says so rather than looking like an empty venue, and an edit returns to the narrowed list.
• Docs, and a French translation, in the same commit.

User interface changes

A Filter details above the places table, with the active filter shown as chips and a Reset link, exactly as the bookings and slots lists present theirs.