Shield Button Regressions

!2096 (merged) split the "Spin" control into separate "Spin" and "Shield" controls. In theory, it's nice to be able to do one without the other (e.g. rolling when landing even while a shield is equipped), but the current implementation introduces these regressions (not "bugs" per se):

• Old configs aren't updated to assign "Shield" to the same buttons (and gamepad axis!) as "Spin" - someone with a config from previous versions will now be unable to use shield abilities or go Super with the same button as before. Making "Shield" copy "Spin"'s buttons necessitates changing "Controls per Key" from "One" to "Several" in old configs. (Likewise, if someone has an old config where Left Alt or LB are already assigned, that will then conflict with "Shield"'s new defaults - but that'll automatically get fixed by making "Shield" copy "Spin" for old configs, which is the more immediately important issue.)
  If this won't/shouldn't be fixed, then having a pop-up ask the player "shield abilities have a new button - do you want to assign it now?" instead for old configs would be nice.
• Assigning "Spin" and "Shield" to the same button does not match v2.2.13's behaviour (which is relevant for the above point) - spamming the button against a wall can still make you Super/un-Super while grounded, and pressing the button in the air will un-Super you instead of floating as Super Sonic. Can be worked around by making it so that if Spin and Shield are pressed on the same tic, you won't go Super while grounded or un-Super at all. (That will still be different from before when having an ability-less shield (but that could be made to not go Super too), but it's close enough for me.)
• Old demos that use shield abilities will de-sync. Fixing this involves incrementing DEMOVERSION, and simply copying BT_SPIN's bit to BT_SHIELD when playing back old replays. (If an add-on gives Emeralds in Record Attack, then the above point is also relevant here.)
• The GC_WEPSLOT8, GC_WEPSLOT9, and GC_WEPSLOT10 constants were removed. As weapons 8, 9, and 10 weren't in the control setup menu and they weren't even put into a player's ticcmd, using them in scripts in the first place could be seen as bad practice (and I'm not sure whether Lua has a reason to use GC_ constants at all), but this could still cause errors for existing scripts. For backwards-compatibility reasons, the constant names could be kept for Lua (just like "BT_USE"), but with a deprecation warning. The constants should probably be aliases for GC_WEPSLOT7 to not trigger for other, unrelated control values.
  Edit: [This script] demonstrates a valid use with input.gameControlDown(GC_WEPSLOT8), which now doesn't work. The script is admittedly made specifically to demonstrate this, but I could imagine a Minecraft mod using that for a 10-button hotbar.
• Record Attack's input display shows jump and spin buttons, but no shield button. Technically not a regression, but still "undesirable". (Those buttons use the acronyms J and S (which I've also seen used in certain add-on menus), but "shield"'s acronym is also S, so that might get confusing?)

Bonus, milder observations, which aren't quite "regressions" in the same way:
- Turning Super, un-Super, and Super in quick succession won't play the "Transformation" sound effect the second time. (This already affected multiplayer when multiple players turn Super in succession, and isn't "exclusive" to the shield button.) Caused by sfx_supert intentionally having SF_NOMULTIPLESOUND.
- Old configs will show Control 'weapon8' unknown, and weapon9 and weapon10. Mostly relevant when executing older configs mid-game, as SRB2's title screen clears the console on startup.
- Edit: The "you collected all Emeralds" tutorial message now uses colour-coding for general emphasis, while it used to be for relevant button names.