Feature: Support forcing local password changes based on time constraints

### Is there an existing request for this feature?

- [x] I have searched the existing issues and found none that matched mine

### Describe the feature

In some environments the local password may be required to be changed regularly and currently we don't have a way to make system administrators to enforce that.

`login` may obey to `login.defs` values, but given that the authd module may override other modules behaviors and that nothing else knows when authd local password has been changed, it's the duty of the authd _brokers_ to check it.

We have also no way to know, at authd level, if a broker requires one or multiple password mechanisms, so we can't just rely on saving the local password in the PAM stack and use other modules to check this.

### Describe the ideal solution

Add broker settings to replicate what `login` does via:

```conf
#
# Password aging controls:
#
# PASS_MAX_DAYS Maximum number of days a password may be used.
# PASS_MIN_DAYS Minimum number of days allowed between password changes.
# PASS_WARN_AGE Number of days warning given before a password expires.
#
```

So, that we initially use a skippable password change request (as we already do in the example broker), and eventually we require the user to change the password.

This may require saving the user last-password change information in the DB too.

### Alternatives and current workarounds

_No response_

Start by reading the example broker and the login/login.defs password-aging behavior described in the issue. Trace how authd brokers handle password-change requests and how user state is stored in the DB. Done means broker settings cover the stated aging controls, support initially skippable and eventually required changes, and preserve the last-password-change information as needed.

Written by the indexing model from the issue text.