Allow for using "Forgot Password" even when a password isn't set

[wes-otf]

If a user doesn't have a password set in Hypha and they select "Forgot Password", they will get a prompt notifying them that a password reset email has been sent while Django quietly ignores the sending of the email. This overrides the default get_users method in Django's PasswordResetForm to include users without a usable password.

As OTF has seen more outlook users have issues with magic links, this would be a nice alternative (even though maybe an annoying extra step) for the time being until we can properly block the link previews.

This PR also includes some very minor UI tweaks I noticed in testing that make reset prompts similar to the rest of Hypha's headers, help texts & buttons.

Test Steps

• Ensure that a user without a password can select the "Forgot Password" option during passworded logins to set a password on their account

[frjo]

@wes-otf Did it not work to block the MS preview stuff with Cloudflare?

In the Cloudflare WAF it should be possible to add a rule that block user agents that contain "MicrosoftPreview".

[frjo]

Overrides like this is no fun to handle when updating Django in the future.

[frjo]

If we need to fix this in Hypha I think a solution that adds an extra step to capture MicrosoftPreview is better.

Clicking the onetime link would then go to a form with a single "Continue" button.

It would force all users to do one extra click but it would also capture MicrosoftPreview and any other similar system.

[wes-otf]

Overrides like this is no fun to handle when updating Django in the future.

I agree, _unicode_ci_compare did feel pretty hacky. Wish there was an easier way because I think setting a password via reset in this context makes sense.

In the Cloudflare WAF it should be possible to add a rule that block user agents that contain "MicrosoftPreview".

It's a cloudflare rule but from what I've seen that might be used for generating web previews (ie. getting OpenGraph info for Teams) rather than being used for safelinks - which I guess makes sense because malicious actors could just block the header as well?

I'm pro-adding a "continue to login" button to the magic link though, might save more headache if other email providers decide to do a similar thing down the road.

If we also decide not to roll with this solution, we should probably also notify the user that their password reset failed because they don't have one set instead of showing the email sent screen