If an attachment is submitted via the API and the filetype is rejected, the
file would be attached anyway. However, if the file was encoded base64, the
content would not be decoded.

And ensure that the email address is trimmed to help matching against email
registered for previous tickets.

Anything that would happen after the last patch was applied would never be
logged, because the system would immediately indicate that no upgrade was
pending.

Fixes #575

Fixes #588

Introduced with the multi-stream upgrader

Drop old mcrypt class

Which will help against clobbering session cookies against other PHP
applications shared on a parent domain of the domain hosting osTicket or in
a parent folder or virtual folder.

* Move migration scripted tasks to the stream folder naming them .task.php.
* Add a MigrationTask abstract class to server as the base of migration
  tasks.
* Move the migration tasks from class.upgrader to the new task files

Add cipher validator - checks to make sure the cipher is valid & available.

Only use 8 bytes (64-bits) for the IV data (salt) for the encryption keys,
except for Mcrypt, which requires you to query the specific length and use
it specifically.

Add test function - basic testing (will be replaced by real test suit)

Incoming messages with empty body and an inline attachment might not have
parts - depending on encoding used.

* Use "-" tag for emails with empty body/message

If there characters in the plain text body of the email that appear like
HTML tags, for instance

From: <sip:527772432@172.18.0.2>;tag=952422a9dd1ap1a6o1

The <sip...> part would be removed by the Format::striptags() call in
Format::sanitize().

The "ft" field does not exist when the attachment migration takes place.
Therefore, attachment migration will fail because the records cannot be
inserted into the database due to the missing "ft" field.

Addresses #589