dissolve "primary" relay notion (`configured_addr`)

[hpk42]

configured_addr is device-local since #8510 but it's still used in four areas:

• which transports sends Smtp::connect_configured reads configured_addr to determine where to connect to for sending messages out. This is maybe the only remaining valid use, and configured_addr could evolve to just mean "last successful SMTP send" while there are no other consumers/setters than the sending logic. Failover for SMTP #8607

• background fetch was introduced before multi-relay support. It uses configured_addr to connect to a particular IMAP relay but it's probably historic. We should be able to connect to all IMAP relays in parallel, as the Context::fetch_msgs_mutex will serialize all fetches. So the fastest relay wins. Imap::new_configured function can be deleted, removing the use of configured_addr with it. I only see upsides.

• used as a pseudo-identity string in OpenPGP User IDs (will be fixed with Autocrypt2), securejoin parameters, location KML (fixed in refactor: Don't store email address in location KML. #8615), backup and key export filenames. They all should go, one way or another, because email addresses are not a good ID after core-V2. Maybe we can just replace it with fingerprint, which is the actual identity. If you juggle multiple profile backups or keys, then fingerprint is the proper distinguisher for identity.

• encryption info: Config::ConfiguredAddr is used but shouldn't. If the encryption dialog is to show two peers always in the same orde (which is actually broken today, because configured_addr is not neccessarily synced).

(i will further edit this issue after more discussion)