Issue #3618282: Weighted lists cannot be reordered by dragging, and booking channels are offered alphabetically

Makes the last five weighted lists draggable, and fixes the one place [#3618261] got wrong.

The two config lists (tenants, booking channels) use core's own DraggableListBuilder. The three content lists (allotments, tariff classes, tariff presets) use DraggableWeightedListBuilder, which is the same thing for a type that holds its weight in a FIELD rather than declaring a weight entity key -- core's DraggableListBuilderTrait is not config-specific, so this is a thin class over it. Weights are renumbered from zero on save, as on the engine's other order screens.

The booking channel fix is a correction to my own reasoning in [#3618261]: I skipped config entity types there because ConfigEntityBase::sort() is weight then label, which is only true where something CALLS it. A selection handler does not, so channels were offered alphabetically. Two bugs, actually -- once the type was recognised, the reorder still skipped them, because it tested option keys for being numeric and a config entity is keyed by its machine name.

Two traps worth naming for the next list converted:

• core's trait wraps the label cell itself, so a row builder must leave that one a plain string and make every OTHER cell a render array. A form table has no #rows.
• getUntranslated() does not exist on a config entity, so the equal-weight tie-break has to branch.

Tests assert what this module decides: a submitted arrangement is stored as a sequence from zero, and a weighted config type is offered in weight order with labels that sort the opposite way on purpose. Both were seen failing with their fix switched off. Core's tabledrag is core's to test.

Verified against a running site: all five screens plus the four from [#3618263], and a real submit that moved a row to the front and renumbered.