This allows for specifying that attachments from something like a new
message should be brokered with autoresponses and alerts.

Preserve text formatting on the internal note posted to a new ticket by
staff if HTML thread is disabled.

This is necessary for some mail clients which indicate encoding in GB2312
but actually use GBK encoding.

This correctly handles a bounce message with the following layout:

multipart/report; report-type=delivery-status
    multipart/alternative; differences=Content-Type
        text/plain; charset="us-ascii"
        text/html; charset="us-ascii"
    message/delivery-status
    message/rfc822

Fixes #1854

This feature addresses a major issue with the initial implementation of the
custom data system. The original system confused the usage of
database-backed field (dynamic-fields) and their corresponding
implementation. This created the need to crate awkward caching pieces to
ensure that validation errors and data was maintained. Furthermore, the
system confused the linking between form instances (dynamic-entry) and the
form used to represent that entry.

This patch addresses the confusion in two ways:

Dynamic form entries do not link directly to the dynamic form. Instead, the
::getForm() method returns something from the forms API directly.
Furthermore, the ::getFields() method does not return dynamic field
instances (database backed / designed fields). Instead, the actual
implementation of the fields from the forms API is retrieved. This allows
the fields to *always* be cached, which helps preserve data and validation
state.

Secondly, the dynamic form uses the same system, so that requests to turn a
dynamic form into a form (via ::getForm) will also result in the same
behavior, again, where the fields are represented as forms API fields rather
than the dynamic fields.

So going forward, the dynamic fields are *only* used to create corresponding
forms API field implementations. The are associated with the dynamic
counterparts as sparingly as possible.

Several mail clients do not return the Message-ID header in a In-Reply-To or
References header as they should. The assumption by such mail clients is
that the email be threaded based on the Subject header. However, osTicket
does not require the ticket number to be placed in the Subject header and so
has trouble threading email from such systems. osTicket embeds a copy of the
Message-ID header (or compatible version) in the body of the message in
hopes part of the message will be returned.

Many mail clients (such as osTicket) strip and clean the HTML when
processing HTML email. Previously, the message-id token was embedded in a
@data-mid attribute, which was likely stripped before the HTML email would
be returned back to osTicket.

This patch suggests that the token be placed in a @class attribute, which
has a much better chance of returning to osTicket.

Follow-up PR to the comment here:
https://github.com/osTicket/osTicket-1.8/commit/06d3a0f3e2a4557ca72faa916859b9315635dfe4

Copy+Pasting images from a ticket thread or from a FAQ article to the HTML
editor and submitting will result in the URL *not* being properly rewritten
for storage in the database. When images are uploaded, a relative URL is
returned from the server and embedded in the HTML editor. However, when
images from the system are copy and pasted into the editor, an absolute URL
with the http:// scheme is included. This URL was not properly handled by
the URL rewriter in Format::localizeInlineImages().

This patch addresses the issue by properly handling both relative URLs from
image uploads and absolute URLs from copy and pasting.

Fixes #1926

Also fix bug where bogus charset names like `iso` were confused with valid
charset names starting with that text, such as `iso-8859-2`.

add __() function for not translated words.

When associating objects via the ::set() method or by adding them to an
InstrumentedList, avoid saving the object immediately. Instead, lazily
update the primary and foreign key of the associated objects.