Use the group password only through a KDF

[sudden6]

This changes the NGC protocol in the following ways:

• The password is turned into a "passkey" through a Key Derivation Function (KDF), which uses the group public id as a salt.
• The API is changed such that the password can not be read from the group again

This has the following advantages:

• The "password" will no longer be stored in RAM in plaintext, although getting access to the group shared state will still allow access to the group. It will now be impossible to get what was used as the current group password in plaintext.
• Allows arbitrarily long passwords, although at the cost of having to always transmit 32bytes for packets where the group password used to be. (IMHO that's not really relevant, as the password was up to (1 to 32)+2 bytes)
• It's good practice to never use plaintext passwords in protocols as far as possible. This PR shows that it's possible, so I'm strongly in favor of implementing these changes to the NGC protocol.

This has the following disadvantages:

• The plaintext password will no longer be known to the whole group once the founder changes it. If peers should be able to invite other peers the plaintext password must be redistributed via some way. IMO this could also be a good feature, allowing the founder to invite people to the group and at some point "closing" the group for new invites by changing the password. An option to workaround this problem would be to allow the founder to optionally send a broadcast to the group (or to select people in the group) with the plaintext password. It really depends on what we want to do though.

In this PR I implemented a PoC on what changes would be needed. It is not fully complete and I think I broke packet encoding somewhere, but it should suffice to show that this doesn't increase the complexity.

[Green-Sky]

afaik, toxcore uses C99, but static_assert is a C11 feature.
https://en.cppreference.com/w/c/error/static_assert

[sudden6]

It's used a bit above, so I think it works. Not sure though why...

[emdee-is]

@JFreegman and @Green-Sky I think we need the Tox equivalent of Python PEPs to get proposals for improvement identified, and prioritized.

If https://wiki.tox.chat allowed logged in users to write then we could use that unless there's something better.

[Green-Sky]

@JFreegman @sudden6 , i think this should be reopened/retargeted to c-toxcore:master for further discussion.

[emdee-is]

Can you make/add a Security label for these kind of issues, so we can keep track of vulnerabilities or rooms for improvement?