This allows defining an [game_presets] tag which contains [game] tags describing how to show the game in the lobby and what settings the game should use.
Functionally this adds an entry per [game] into the Matchmaking section of the MP lobby:
* If a player clicks Join and there are no previously created games from this "queue" that are open, then the server instead responds telling the client to create the game. The game is created directly using the settings defined in its [game] tag, so for the player it looks like they clicked join and then go straight to the MP staging screen.
* If a player clicks Join and there is an open game created from this "queue", then the server instead responds telling the client the actual ID of the game to join and the client then joins that game just as if they had clicked Join on a normal game.
Currently only implemented for mainline.
In order to properly distinguish the overloads, the second takes the keywords instead of the filter text. This was confusing, so now `translation::ci_search` properly handles vector input. Removes the need for the second overload.
Also adds a proper move assignment operator to canvas. styled_widget::set_config was removed since it's not needed as of dfa09cd9d9be44ca036e6a506bdcd3116862b37e.
Testing now, pango weight markup correctly works with the Lato weight variant files present and breaks with them missing. Seems the issue I documented back in 2018 is noo longer the case, and thus we don't need this workaround.
This was first added by mordante in a36e1ee69648fcb6f4e0600d78bf99f442bbc9cd. The code around it was subsequently removed in b217903c070e5a0de9162250108ea8f0e9ba5ad9, and had since remained functionally useless.
It was briefly called to action as part of #8510 (see 9b38089db0f2fca2374f5860b510af34454b89c7), but that usecase was temporary and the hardcoded max width subsequently removed in 4cb9df8e6c0307e065c29d2d7aad07debdc5e0da.
For some reason, if we store a t_string in the class and attempt to parse it later, it breaks text boxes (text will be there but not render) (see #9995). Using an std::string does not have that problem. I don't know why.
I considered a variant<typed_formula, t_string>, but since attribute_value is a variant under the hood, it seemed simpler to just use it directly. If that turns out to be a performance hit, we can deal with that later...
Closes#10001
