Update bulk user deployment logic to support ahead of time provisioned SSO accounts

The behavior what happens when a user logs in using SSO with an email that is already being used for a local nmaas account has been tested.

1. If the local account doesn't have the property `saml_token` set, then when logging in via SSO, a completely new account is provisioned
2. If the local account has the property `saml_token` set to the identifier obtained from Keycloak (currently email for the demo SAML integration in QALAB2), the two logins can be used interchangeably - the user can login with their local password or opt to use SSO.

Taking this into account, the bulk user deployment functionality should be altered so that:

1. a new optional CSV field is present (by default is set to false) that will control whether the provisioned account will have SSO enabled or not. If SSO is enabled, then the `saml_token` field should be set to the same value as the `email` field.
2. email notification is sent for newly created accounts in bulk
   1. if the account has SSO enabled, the email template does not include a password reset link and simply instructs the user to use their institutional account for the login, using the `Federated login` button in the portal.
   2. if the account is not SSO enabled (it is a local nmaas account), the email template also includes the password reset link.
3. the sending of the email notifications for newly created accounts in bulk should be hidden behind a feature flag that will default to `true` and can be altered from the global settings page of nmaas.