The generation now happens in a subquery inside the INSERT statement instead
of separate client-managed query. This should also reduce the risk of race
conditions.

Service and non-service users may now use the same UID range.

Previously User used salted SHA512 with OpenLDAP-style prefix syntax and
Signup used crypt. Both models had their own hashing and verification
code. Now both use OpenLDAP-style syntax with support for all traditional
formats including crypt. Salted SHA512 is used for new User and Signup
passwords.

Existing Signup objects are migrated to the new format and remain functional.
User passwords now support gradual migration to another hash algorithm when
it is changed in the future.

This code is planned to be used for database-stored API and OAuth2 client
secrets.

Closes #127

* Removal of ldapalchemy and LDAP mocking support
* Removal of dependency on ldap3 (except for the migration)
* Remaining "LDAP_<name>" config keys are renamed to "<name>"
* Web interface to create, edit and delete groups
* Consistent foreign key, cascading and nullable configuration on all models
* User/Group.dn is replaced with numeric User/Group.id
* User.uid is renamed to User.unix_uid (to differentiate with new User.id)
* Group.gid is renamed to Group.unix_gid (to differentiate with new Group.id)
* All User/Group/Mail related routes now use the database ids instead of uid/gid/dn
* PasswordToken/MailToken now reference users directly instead of storing loginnames

The database migration (optionally) uses the v1 config keys to connect to
an LDAP server and to import all users, groups and mail forwardings.

The test cases effectivly tested if the user_acl_check works which is already
covered by other test cases.

Prior to this change user passwords were not validated on change aside from
their length, but validated on login/bind by ldap3 with SASLprep. Instead of
using SASLprep on password change, this change restricts passwords to 7-bit
ASCII without control characters. Control characters are forbidden by
SASLprep. Multi-byte characters are uncommon in password, especially in those
generated by password managers. This ensures that passwords are always
SASLprep-safe without implementing the rather complex SASLprep algorithm. It
also allows us to fully describe the alphabet restrictions in the relevant
forms.

Fixes #100

Co-authored-by: psy <psy@darmstadt.ccc.de>

Add a few unit tests as well as integration tests that cover almost all views. Also fixed a lot of HTML validator errors.