Filters should not be run alongside basic ticket validation

The quickList() method will attempt to ask the database to find filters that
might match the incoming ticket information. The idea is that MySQL is
likely faster than PHP. The problem is that it assumes positive logic is
being utilized.

This patch adds all filters with at least one rule with dn_contain
(does-not-contain) or not_equal (not-equal)

Use a PHP setup which uses the built-in PHP tokenizer to parse and traverse
PHP scripts to determine (possible) access to uninitialized variables

Moved to an initial form which specifies the ticket's priority and issue and
changed the rendering to render things properly. Now the user can decide
where priority shows on the client side, and the priority privacy setting is
placed in the dynamic form wizard.

The standard form is added to every ticket without option. Extra forms can
be defined and associated with help topics which can additionally be added
to tickets upon creation. This allows for standardization of the dynamic
data location for searches and filtering.

Implemented advanced search for dynamic data. Along with reinstating the
basic ticket search on keywords

Implemented ticket filtering on dynamic data for both keyword searches as
well as searches for special fields (drop-down lists, etc.)

Phone number for users is now completely optional

Process inline attachments in thread entry and support inline images in
piped emails

Support inline images across the system, with draft support

Migrate to a single attachment table
    That way we don't need a new table for everything we need to attach an
    inline image to (like a signature, for instance)

Add richtext support for internal notes

Implement images on site pages

* Image paste in Redactor
* Make non-local images optional
* Placeholder for non-local images
* Fix local image download hover
* Don't re-attach inline images

The email filtering feature supports a 'Use Reply-To' feature, but seems to
never have been implemented. This patch officially supports using the
Reply-To email header as the From header for emails matching the filter.

This is one of the last major hurdles to make osTicket fully translatable.
With the advent of 1.7.0, database migration is based on the MD5 hash of the
install SQL file. Therefore, the install SQL script cannot be modified (ie.
translated) or else the system cannot be migrated, since the MD5 hash will
no longer match up.

This patch pulls initial data out of the install file so that it can be
translatable. Eventually the install worksheet can allow a drop-down box of
the default system language. The default data from that language will be
loaded into the system.

Spelling, grammar and readability in upgrader documents
  - Tweaked spelling, grammar and wording to make the text of the upgrader
    pages more readable.
Fixed spelling regression
  - Higly —> Highly
Spelling and readability fixes for /include/class.* files
  - Fixed some spelling mistakes
A couple more spelling/readability fixes.
  - More fixes

Take into account emailId when loading all filters

Force target selection on filter form
Add minor code improvements

* Change table name from ost_email_filter* to ost_filter*
* Add patch for target field.

And remove unsupported filter of email headers

This will include other information described in email filters that mark the
email as rejected. For instance, sender-name, message body content, etc. It
also allows for other matching methods (contains, !=, !contains), rather
than the quick banlist method from EmailFilter::isBanned().

Also fix bug in Filter::__construct that prevented any filter from ever
matching