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')`.
This was noticed as a problem after `Unread.doesRoomHaveUnreadMessages` started being called a lot more frequently. Down the call stack, `shouldHideEvent` is called which used to call into the `SettingsStore` frequently, causing performance issues in many cases. The `SettingsStore` tries to be as fast as possible, however there's still code paths that make it less than desirable to use as the first condition in an AND condition. By not hitting the `SettingsStore` so often, we can shorten those code paths.
As for how much this improves things, I ran some profiling before and after this change. This was done on my massive 1200+ room account. Before it was possible to see nearly 2 seconds spent generating room lists where 20-130ms per room was spent figuring out if the room has unread messages. Afterwards, the room list was generating within ~330ms and each unread check taking 0-2ms. There's still room for improvement on generating the room list, however the significant gains here seem worth it.
