See MDL-79373 (& MDL-74489 & MDL-78961...) regarding the current hardcoding of known password config and the potential problems associated with that:

1. Easy for it to become out of sync (when new password configuration is added)
2. Easy for typos
3. We can end up unintentionally exposing site passwords in shared preset files, despite the admin asking that they be excluded (thanks michaelh!)
4. No default support for third-party plugins (relies on the admin knowing such config exists and manually editing the settings) above
5. Related to the above, it's a clear breach of our inter-component communication rules (core should not have or require any knowledge of installed components)

We should have a better way of implementing this - an obvious solution would appear to be to treat all configuration of type admin_setting_configpasswordunmask or admin_setting_requiredpasswordunmask as "sensitive", removing the onus on the admin to define them. This would also mean third-party plugins would get automatic support too

We could then leave the current textbox configuration for any additional settings the admin wants to consider as sensitive (e.g. the salt values[*] we added in MDL-74489)

[*] We might also ask why the salt configuration are not password fields themselves - perhaps they should be, but that may be beyond the focus of this ticket