[Autodiscovery] Change ConnectionSettingsDiscovery interface

We need to make some changes to the ConnectionSettingsDiscovery interface to be able to make optimal use of the functionality provided by SrvServiceDiscovery.

The ProvidersXmlDiscovery autodiscovery method either gives us a complete set of server settings (exactly one of each incoming and outgoing server settings) or it doesn't. With ThunderbirdDiscovery that's not necessarily true, but it probably is in practice. But with SrvServiceDiscovery there's a real chance we could get any combination of one, none, or multiple server settings for both incoming and outgoing server. This is fine and we want to make use of all the information we can get in order be able to automatically set up an account. For the whole plan see issue #4721.

Input: When a ConnectionSettingsDiscovery implementation is used in a later stage, we might already have working server settings for either the incoming or outgoing server, and are only looking for settings for the missing server. So there should be a way to let the ConnectionSettingsDiscovery instance know which type of server settings it should look for (incoming, outgoing, or incoming + outgoing).

Output: We want to support situations where a discovery mechanism returns more than one server setting candidate for each server type (incoming, outgoing). We also want to support getting server settings candidates for only one server type. With SrvServiceDiscovery (and maybe other methods in the future) we need to distinguish between trusted and untrusted server settings. Where trusted settings are ones we can use to automatically set up an account. Untrusted server settings will only be used after the user has confirmed it's okay to do so. Since the ServerSettings class we currently use is also used elsewhere, I suggest creating a new class that is similar but specific to the autodiscovery phase.

With ConnectionSettingsDiscovery changed, we can update SrvServiceDiscovery to expose all the information it collected. Whether or not settings from DNS can be trusted should be determined by either
a) are the SRV records signed via DNSSEC
b) is the server's host name identical to the email domain or a sub domain of it, e.g. we trust mail.domain.example as incoming or outgoing server for user@domain.example.

This is a sub task of #4721

Start by reading the ConnectionSettingsDiscovery interface and the ProvidersXmlDiscovery, ThunderbirdDiscovery, and SrvServiceDiscovery implementations, then review the broader plan in issue #4721. Done means the interface can request incoming, outgoing, or both server types and represent multiple trusted or untrusted candidates for the later SrvServiceDiscovery update.