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.

Which indicates permissions are not windowed by an object's department

This patch converts the central file and threading classes over to use the
ORM.

Key permissions definition array
Move canned and faq permissions to their respective classes.

Allow usage of something like `%{ticket.user.organization.var}`

Conflicts:

	include/i18n/en_US/form.yaml
	include/staff/templates/dynamic-field-config.tmpl.php
	include/staff/ticket-view.inc.php
	include/staff/tickets.inc.php
	scp/js/scp.js

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".

Add other locations as well a failsafe for the htmlentities() call

Auto assign tickets to organization's account manager only if the flag is set and as
the last resort i.e topic or filters assignment takes precedence.

Allow developers to specify a sorting position for groups of fields
selectable in the criteria select drop-down

Make the organization page happy!

Use .domain.tld to accept all subdomains of a parent

This is a slight edit over the previous implementation of the same feature.
Previously, an "account" was required, which implies a user account with a
password. This implementation simply requires a user record. Importing of
users by organization domain is still supported -- even if the user does not
yet exist.

Previously we required an account to associate a user to an organization.

Deleting an organization with users will simply orphaned the users.

Don't save 'name' as dynamic data for organization form.

Add organization class