Issue #3615192: Filter a venue's places by section, subsection and row

A hall holds well over a thousand places, listed fifty at a time in the order they were created, so reaching one row of one section meant paging through the house and reading ids.

• VenuePlaceFilterForm extends the same FilterFormBase as the bookings, slots, orders and managed-resources lists, filtering on section, subsection and row — the three the list already shows.
• Its 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 listing is ordered section, then row, then position along the row: the order a hall is read in rather than the order places happen to have been created.
• The row operations carry the active filter in their destination, so editing a place from a narrowed list returns to that list instead of the top of the hall.

FilterFormBase assumed a collection route with no parameters, and a venue's places are reached by a route naming the venue, so it gained a collectionRouteParameters() hook defaulting to none. The four existing subclasses are untouched by it.

Coverage

Functional, because a GET filter is only exercised by a real request: the options offered match the venue and exclude a row it does not have, section and row narrow together to their intersection, the subsection narrows alone, a filter matching nothing says so rather than looking like an empty venue, and following Edit from a narrowed list comes back to it.

One assertion worth noting: the section names are also filter options, so "does the table still show Galerie" has to be asked of the table's own cells, not of the page. Asking the page passes while the list is wrong.