Check if the newly set password is the same as the old one

[DL6ER]

What does this implement/fix?

This is especially worth adding in the context of forced passwords (via env var) as the password is always "set" on each config change. This PR effectively prevents FTL from wiping all sessions and forcing the user to re-login when changing even settings which are 100% unrelated to the API.

---

Related issue or feature (if applicable): N/A

Pull request in docs with documentation (if applicable): N/A

---

By submitting this pull request, I confirm the following:

1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
2. I have commented my proposed changes within the code.
3. I am willing to help maintain this change if there are issues with it later.
4. It is compatible with the EUPL 1.2 license
5. I have squashed any insignificant commits. (git rebase)

Checklist:

• The code change is tested and works locally.
• I based my code and PRs against the repositories developmental branch.
• I signed off all commits. Pi-hole enforces the DCO for all contributions
• I signed all my commits. Pi-hole requires signatures to verify authorship
• I have read the above and my PR is ready for review.

[rdwebdesign]

Do we still need this check?

FTL/src/api/config.c

Lines 289 to 294 in 2406e1a

	if(strcmp(elem->valuestring, PASSWORD_VALUE) == 0)
	{
	// Check if password is unchanged (default value set by PASSWORD_VALUE)
	log_debug(DEBUG_CONFIG, "Not setting %s (password unchanged)", conf_item->k);
	break;
	}

[DL6ER]

Do we still need this check?

FTL/src/api/config.c

Lines 289 to 294 in 2406e1a

	if(strcmp(elem->valuestring, PASSWORD_VALUE) == 0)
	{
	// Check if password is unchanged (default value set by PASSWORD_VALUE)
	log_debug(DEBUG_CONFIG, "Not setting %s (password unchanged)", conf_item->k);
	break;
	}

Yes, this check serves a totally different purpose: The web interface sets the password field value to PASSWORD_VALUE and when the web interface sends back exactly this string, we assume the password is not to be changed. However. nobody will do this intentionally (outside the web interface) so it isn't concerned with all the changes discussed here.