[Feature] Introduce sender-blacklists (on both global/admin and user level)

[chrisblech]

While using a self-hosted instance für some months now with a throughput of more than 5000 mails/month and consequently manually disabling spam-sender (on contact level), simplelogin blocks about 600 SPAM mails per month.
When looking at the remaining 350 spam mails that are still forwarded to my inbox (and get caught by GMails SPAM sensor), I realize that a significant amount of them belongs to "spammer-domains" or at least follow the same pattern.

This PR adds two levels of sender blacklists to SimpleLogin: Admin and Users can use this to block sender addresses (or whole domains / TLDs) by regex pattern.

• New DB table global_sender_blacklist (pattern regex + enabled + comment)
• Admin UI (Flask-Admin) and User UI (Settings) to manage patterns
• Inbound SMTP handling: unknown senders matching the blacklist create a Contact that is disabled. The following (untouched) mail handling logic will using the pre-existing behavior as a blocked Contact (2xx vs 5xx depending on user.block_behaviour)
• Users can override the global logic, by (re-)enabling a disabled Contact.

Migration and tests are included.

[Bonus/Example] My personal blacklist patterns:

• @novastek\.homes$
• @devalser\.hair$
• @tabot\.com\.tr$
• @casang\.vip$
• ^[a-z]+[0-9]{5}@[a-z]+\.[a-z]+\.shop$
• @juntadeandalucia\.es$
• @resend\.dev$

[acasajus]

Please move the management of the ForbiddenEnvelopeSender into a separate file that can be tested and called from other places instead of adding more code to the settings page.

[acasajus]

Also there are no tests for per-user entry, regex validation on entry or deletion.

[chrisblech]

@acasajus thank you for your valuable feedback. I tried to address all your suggestions, hoping there is nothing left and this PR can find its way into this gerat product :-)

[chrisblech]

Hi @acasajus @cquintana92 ! Just a friendly follow-up on this PR.

I have addressed all review comments and updated the implementation accordingly. Since then, the PR has been waiting for a while, so I wanted to ask whether there are still any concerns or if anything else is needed before this can be considered for merging.

I've been running this change in my own self-hosted instance for some time now, and it has significantly reduced the amount of spam reaching my mailbox. As mentioned in the PR description, the feature is completely optional and does not change the default behaviour for existing users.

If there are any additional changes, refactoring, tests or documentation updates that would make this PR easier to merge, I'd be happy to work on them.

Thanks again for taking the time to review it.