This patch adds an 'email' format to ThreadBody::display() which allows
formatting the html/text bodies specifically for email. Previously, there
was ambiguity between the html view (which included inline image support and
clickable links) and the email view, which requires neither.

If an email contains both inline and separate attachments, the previous
logic would detect all the attachments as inline.

Separate attachments have the `cid` set to `false`. This will pass the
`isset` test, which would cause the logic to search through the body for a
string of `cid:`, which would very likely be found if there was another
inline image somewhere in the body of the email.

With the advent of 1.9, the original, plain text email is saved in the
thread table. If a system has the HTML ticket thread enabled (which is the
default), if the plain text message is placed in the email template (which
is always HTML), it will not be formatted as correct HTML and the whitespace
will be collapsed.

This patch addresses the issue by always returning HTML from the asVar()
method, which is used to embed the thread post into a email template.

This occurs for attachments added via the staff or client web interfaces

It is perfectectly fine to have an image cited in an HTML body similar to:

<img width=909 height=302 src=cid:image002.jpg@01CF5426.BF5A72A0 alt=image>

Which may or may not have quoted @src attribute, and may very well have an
at sign (@) somewhere in the attribute text. The previous regular expression
would not match such a @src attribute.

It is the defacto standard to reference an inline image in an email by
referencing the Content-ID header of the referenced attachment in the @src
attribute of the image. For instance, `<imc src="cid:image001.png">` where
the `cid:` scheme of the attribute indicates that the referenced image URL
is a separate content of the email. The image attached to the email would
have an accompanying header like: `Content-Id: <image001.png>`. However,
some mail systems, including a certain fax to email service, do not
correctly indicate the location of the image with the content-id URL.
Instead, the referenced image tag would be `<img src="image001.png">`

This patch addresses the issue by searching the message body for all
references to attached content-id's in all @src attributes with or without
the content-id URL scheme indicator. Previously, such images would not be
displayed inline in the ticket thread.

References:
https://tools.ietf.org/html/rfc2392

It is perfectectly fine to have an image cited in an HTML body similar to:

<img width=909 height=302 src=cid:image002.jpg@01CF5426.BF5A72A0 alt=image>

Which may or may not have quoted @src attribute, and may very well have an
at sign (@) somewhere in the attribute text. The previous regular expression
would not match such a @src attribute.

Thread entries now have a flexible `format` specification, which allows the
system to save the format alongside the original text. This allows the
system not to have to convert everything to HTML when storing in the
database

The bug prevented attachments from being sent out if it was previously
attached to the ticket - for example, you could resend a file to end user.

If an email loop is detected, in addition to dropping the message, also log
an error to the system log, but do not send an email to the administrator in
the event that it is the administrator's email that is looped.

Outbound message-ids are predictable, with a consistent code unique and
static to each osTicket installation. This will help detect email loops
where message is delivered back to the system in an email loop.

If images are included inline in an email and the quoted-response removal
algorithm drops them, then silently drop the attachments

Join to staff/user tables to get current name when fetching thread entries.

This approach will help detect responses to the ticket thread from mail
clients which do not include the References and In-Reply-To MIME headers.
This also allows the Subject line to continue to omit the ticket number.

level.
Handle cases where thready body is sent in as a string

We're going to assume HTML of html thread is enabled - otherwise text is
assumed.

Cleanup and make HTML safe by default
Strip empty lines in TEXT content

This will be helpful to keep track of whether a text is html or text and
provide a way to convert it exactly once.

Rename routines to make it a little clear on what they do