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.

Handle missing `intl` module
Handle crash translating the staff login banner, when the %translation table
    does not yet exist
Handle `allow_client_updates` never having been configured
Handle staff login without @lang and @extra attributes in database

This will look through the database and find images which appear to be
inlined in thread entries, but are not recorded as inline. It will update
the %ticket_attachment table to reflect the inline disposition of the
images.

This will be used for greater flexibility in visibility and requirement
settings.

And manage it with updates to tickets. This will ease the sorting and
display of tickets based on the time of last update in the ticket queues

This will contain the effective due date of the ticket — either the due date
or the estimated overdue time of the ticket based on the SLA settings. It
will be maintained with ticket updates.

orm: Add greater support for expressions in order_by