Add support for Authentication models

[PhilippMDoerner]

Similar to Django, in order to provide "log-in" capabilities, an Authentication Model is required.
Admins can then authenticate against that model.
That means a model where the user can store a password and have it automatically get hashed according to some configured encryption method.

This means re-building Django's way of encrypting, including providing several ways to do so that can be swapped out depending on a configuration value (only new values get hashed with the new method, old entries can't be rehashed but must still work).

Further it means supporting password fields in the frontend forms.

Further it means that the extension must be able to check whether the model already exists on the database and if it doesn't, either add it or throw an error that it must be added.

[enthus1ast]

Some option to rehash could be:

1. if a password must be rehashed, it could be done on the next login of the user.
   The issue here is, that maybe a user never logs in again, thus the password is never rehashed
   and become insecure over time.
2. if passwords are not on a defined security level. The hash itself could be rehashed with the newer standards, this requires of course that all the hashing methods must be stored and all must be applied in order to login.

[PhilippMDoerner]

Realization:
Should I add a default way to authenticate against Snorlogue, it would provide a way to allow each authenticated user to use different connections. This only really matters in the context of a postgres database.

What it would enable though is that if user X is registered, then they can get connections to postgres with a user mapped to their kind of account. This means that Snorlogue could provide different levels of database access for different kinds of users.

This is irrelevant for sqlite as sqlite has no way for permission management.

[PhilippMDoerner]

This is actually much less of a big deal than before. I've learned a decent amount in password hashing since then and written nimword which deals with that complexity, thus leaving it out of Snorlogue. I'm not sure anymore if it would be terribly difficult to just replicate Django's auth models and have that as a sub-package in Snorlogue.