The `BottomLeftMenu` component is not used in the new design. This removes the
component and also any images and sub-components that were only used by it.
Fixes https://github.com/vector-im/riot-web/issues/6435
This is done through an on-the-fly inverter for the settings. All the settings changed are boolean values, so this should be more than safe to just let happen throughout the SettingsStore. Typically a change like this would be done in the individual handlers (similar to how setting names are remapped to different properties or even different storage locations on the fly), however doing that for this many settings would be a huge nightmare and involve changing *all* the layers. By putting a global "invert this" flag on the setting, we can get away with doing the inversion as the last possible step during a read (or write).
To speed up calculations of the default values, we cache all the inverted values into a lookup table similar to how we represent the defaults already. Without this, the DefaultHandler would need to iterate the setting list and invert the values, slowing things down over time. We invert the value up front so we can keep the generic inversion logic without checking the level ahead of time. It is fully intended that a default value represents the new setting name, not the legacy name.
This commit also includes a debugger for settings because it was hard to visualize what the SettingsStore was doing during development. Some added information is included as it may be helpful for when someone has a problem with their settings and we need to debug it. Typically the debugger would be run in conjunction with `mxSendRageshake`: `mxSettingsStore.debugSetting('showJoinLeaves') && mxSendRageshake('Debugging showJoinLeaves setting')`.
The classes on the search box input were changed without updating the focusing
loop in the room filter which used one of these classes as a boundary condition.
This led to a case that could loop forever.
Regressed by #2267.
Fixesvector-im/riot-web#7926.
this does the filtering in RoomList instead of RoomSubList, so
we can hide sections that don't have any results.
The filtering does happen with every rerender of RoomList,
but only does something while searching, so the performance
implications are probably negligible.
