[Feature] Allow user self-update of email and notification of changes

[fmigneault]

Context

With the integration of user self-registration feature (#435), users can self-register to Magpie (if enabled).
During this process, email confirmation is accomplished to validate that the registering user can receive notifications to submitted email address.
Because user can also self-update their accounts (following whole approval process of registration), it was possible for the user to immediately change the email without new confirmation.

To reduce the scope of the (already large) feature #435, email update was disabled for the moment when user-registration is enabled (see FIXME notes with this issue number in the code).

Magpie/magpie/api/management/user/user_utils.py

Lines 194 to 198 in 197d596

	# FIXME: disable email edit when self-registration is enabled to avoid not having any confirmation of new email
	# (see https://github.com/Ouranosinc/Magpie/issues/436)
	update_email_admin_only = False
	if update_email and asbool(get_constant("MAGPIE_USER_REGISTRATION_ENABLED", request)):
	update_email_admin_only = True

A message is displayed to indicate to communicate with an administrator for the time being if email change is needed by a user.
Administrators can still enforce a change of email as required.

TODO

• Whenever a user self-update occurs that requires email change, a temporary token similar to the ones created during user registration process should be generated. The token/hook would send an email to the new user email to request its confirmation.
  Once confirmation is received (from link in new email), the email address change would be applied to the account.

• A notification email should also be sent to old email for double checking the change whenever a change of email is requested.
  (eg: "an email update was requested for your account <user-name> for <magpie-url> on <datetime>")
  This would allow a user to raise a flag (or acknowledge and discard the email) if this change was somehow not requested by them directly.

• Special logic will be required to handle this type of change via temporary tokens, since user column refers to a current state of a pending or registered user. In this case, we require a pending-state of a field for a registered user. Probably a separate field (no specific value for future cases - per tmp token type?) could be a method to handle this.

• All API and UI locations that temporarily disable email update will need to be adjusted to support pending email validation.