fix: keep the wordpress hash when it already matches the new password

[YvesCesar]

Closes #22

BeforePasswordUpdatedListener now reads the current WordPress hash with the get_wordpress_user query and only writes a new one when that hash does not match the new password. Since that query also matches by email, the hash is taken from the row whose uid is the user, the same row the set_wordpress_password query updates. A password change that started in WordPress reaches Nextcloud with a password WordPress already stores, so the hash, and the auth cookie tied to it, stay untouched. A password changed in Nextcloud is still written to WordPress.

Tests (tests/Unit/Listener/BeforePasswordUpdatedListenerTest.php, against a SQLite database):

• a new password is written to WordPress;
• a hash that already matches the new password is kept;
• the new password is written when another user has the login as email;
• a user missing from WordPress leaves the other users untouched.

tests/bootstrap.php gains stubs for IUser, Event, IEventListener and BeforePasswordUpdatedEvent, like the existing IConfig one.