Refactor implementation data format

[fingolfin]

Currently, we store the list of supported protocols as arrays like this:

protocols:
    cipher:
        - aes256-cbc
        - [email protected]
        - [email protected]
        - ...

I think this should be changed to a dictionary instead. This has multiple advantages:

• it makes it a bit easier to test in the code if a client supports a protocol;
• it deemphasises the (arbitrary) ordering of protocols
• it allows adding extra information to the support for a given protocol, say, the first version the protocol was supported (the idea being that normally, the keys are booleans, but they could also be strings or more complex data).

Hypothetical example

protocols:
    cipher:
        aes256-cbc: yes
        [email protected]: "since version 2.0"
        [email protected]:
              supported: yes
              note: "since version 3.1"
        bad-algo:
              supported: no
              note: "supported dropped for security reasons in 2.7"
        ...

(Not sure whether the last veriant, with a full sub-dictionary of data, is ever needed... perhaps skip it for now, and only add it if we encounter cases that would benefit form it?)

[fingolfin]

Actually, thinking some more about it, the sub-dict variant might be highly useful if one also wants to distinguish whether e.g. a cipher is supported vs. "enabled by default". E.g. the "none" cipher may be supported in principle by an implementation, but a good implementation will disable it by default. Same for other unsafe protocols.

[fingolfin]

Also, it actually makes sense to keep the protocols in a list (i.e. ordered,) as that can be used to represent the default order in the implementation (i.e. which protocols are preferred.