Back the section settings with the cache bin, so a venue layout is read once and not per request

Item 3 of [#3615587]: the same cache backing the slot tariff lookup got in [#3615440], applied to SectionSettings.

A configuration's section settings are the venue layout: which areas it opens, closes or pools. Operator-typed, changed when somebody edits the hall and never because anybody booked. Core caches an entity load and never caches an entity query, so that layout was read from the database once per request, for data that had not moved between them.

Measured

Same rig, same tests, before is bfdb1f98.

	before	after
drawing the place map, warm	9	7	−2
taking a place, the recurring click	20	19	−1
cache tag lookups, render / click	6 / 1	6 / 1	unchanged

The render gains two because the section settings are what that page is drawing, and it asks for them on both of its requests. The click gains one.

Untagged, and purged narrowly

The entries carry no cache tag, for the reason SlotTariffLookup's carry none and AllotmentSettings::inUse() carries none: a tag is validated on every read, and validating one the request has not seen costs a cachetags lookup of its own, which is most of what the entry saves. Measured on the earlier change: tagging cost back one of the two queries it saved.

So PlacementHooks::configurationSectionWritten() drops the entry of the configuration a setting was written for, on insert, update and delete, plus the configuration a moved setting came from. That is also narrower than a list tag would be: editing one hall leaves every other hall's entry standing, where yoyaku_configuration_section_list would drop all of them at once.

What it costs is that the invalidation is ours rather than core's. A row written around the entity API would leave an entry nobody drops. Everything here writes through entity save, so that is a rule we keep rather than a hope, and it is stated on the class.

Tests

SectionSettingsCacheTest covers both halves of the bargain, because either alone is worthless: a later request costs no query, a setting just saved is applied, a mode changed on an already cached configuration is applied, and deleting the last setting lets the section default back. It was watched failing against unfixed code before being kept.

Not in this

AllotmentSettings is the other half of item 3 and is not here: it appears in neither measured page, so its win is on paths that have no number yet, and I would rather measure it than assume it. The pre-lock capacity pass is item 1 and waits on [#3615593].