Previously, this was not ported properly now that multiple selections are
supported in the choice field and derivatives.

There was a slight issue when transitioning from a short answer field to a
drop-down field, and when the CDATA table is dropped and rebuilt.

Prior to osTicket v1.9.4, drop down lists only allowed for a single entry.
After upgrading to 1.9.4 the database data for drop downs changed to allow
for multiple entries. However, the old data format was not properly handled
by the SelectionField::to_php() method which handled interpreting and
upgrading the database data.

The real bug was setting the source of the ticket form — not the fallback to
the form entry source.  Falling back breaks edits.

This patch fixes a small glitch where validation might be bypassed for
fields for agents. Previously there was a glitch where required fields would
have their validation errors ignored.

When processing the value of a DynamicFormEntryAnswer, if there is no
database-backed, value, then use the value of the associated field.

This allows administrators to select a default value for selection fields
deriving from Custom Lists. This has been implemented on the ChoiceField,
but was forgotten on the SelectionField

  * Use the title of "Information" with internal tag of "info"
  * Add "Visibility" column to UI and retire "Required" and "Internal"
    columns
  * Add visibility selection to new fields and show visibility to the user
    information fields when displayed on the ticket details form
  * Make the visibility settings translatable
  * Use constants internally for visibility configuration detection
  * Use a larger input when managing the information HTML content
  * Fix validation errors for new fields
    * Enforce new field name uniqueness
    * Enforce new field name character validation

Hide multi selection option for typeahead selections

This will be useful for maintaining arbitrary list of items. ListObject
should be used in the place of ArrayObject

Furthermore, revamp the __cdata system to better support multiple selection
fields. Drop the `.._id` fields and use a coalesce of the ID value of the
entry value or the entry value itself. For JSON backed fields, strip some
JSON characters to result in a comma-separated list.

The search engine now uses MySQL FIND_IN_SET to analyze a search selection
in advanced searches. Also, interaction with the MySQL full text search
backend is fully supported.

Not just the SelectionField. This will make room for the InlineFormField

This will allow for more complex widgets to be added as plugins which
include css and javascript media files without manually adding header or
footer lines.

And allow for @context to add context to the bare string literal. For
instance,

    /* @trans, @context "noun" */ 'Open'

Would mark the string 'Open' translatable with context "noun".

Always support and consider multiple values — even using the typeahead
widget.

Always save a key/value hash of the selected value(s). However, if the field
does not have the multivalue configuration setting, then retrieve just the
key with the to_php() function. to_database(), however, will always return a
JSON string with the value(s) formatted as a hash array.

This patch fixes an issue where a fatal error would be triggered if the
current value of a selection field on a custom form was a custom list item
that has since been deleted.

Also add some logic to the POT builder to warn about incorrect arguments to
the __() function and friends as well as warn about _() usage.