Logic error in Block user account setting

Changed the title to better reflect issue. Attached is screenshot of behavior and settings.

Client requires this module, so took a look at code and it appears that this functionality never worked. I changed the logic a bit:

When a user account has an expired password AND the setting is to enable them to change their password, the account is now flagged to be blocked via a $_SESSION variable rather than setting the account status to 0 right away. This enables the user the opportunity to change the password.

If the form is submitted and the password is changed, then this $_SESSION variable is cleared. If, however, the user navigates away from the form, the account becomes blocked via hook_init() keeping tabs on this $_SESSION variable.

I refactored the account blocking code into a separate function, and tested against both the default user edit form and the contrib password_tab form. None of these changes should impact other functionality (e.g. immediate blocking on expiration, notification of impending blocking, cron blocking, etc.)

Actually, after looking at Force Password Change patch, I think that is the better approach (dedicated table versus session). That patch still does not solve the logic issue discussed above, but I will roll another patch to address which requires the Force Password Change patch.

I have included the fix in Force Password Change patch #11 since it is dependent on that functionality. Marking duplicate.