Names parsed from incoming emails are stored in the database as is. This
pull request addresses potential XSS vulnerability due to improper display
of unsanitized names. Going forward names will be scrubbed on create.

Fixes #958

Add ability to disable canned responses
Fix team drop down selection
Remove priority escalation setting in SLA page (implementation is on todo
        list)

Accept desired $format as part of class instantiation. System default is
used when none or an invalid format is provided

Previously, there was a bug in the ORM where magic properties would need to
be declared in the model class.

If a client initially authenticates with an external source such as Google+,
the user should still have the ability to set a password via the password
reset mechanism.

It is possible that a recipient received and processed by the system may not
have a name set. In that case, the email mailbox should be used. As a
failsafe, avoid crashing if the User::save() should fail.

This is a slight edit over the previous implementation of the same feature.
Previously, an "account" was required, which implies a user account with a
password. This implementation simply requires a user record. Importing of
users by organization domain is still supported -- even if the user does not
yet exist.

  * Auto confirm remote accounts
  * Don't send out emails for remote account activation
  * Forbid password changes on remote accounts

Previously we required an account to associate a user to an organization.

Show user status on the user listing table

Useful if the staff members administratively configure a static password
that the user should never change.

Add CLI import/export support for organizations