The parser of the ext_tables.sql file removes double blanks
from the input line - but only once. So if there are multiple
blanks at least double blanks remain and irritate the later
comparison about whether the field definition is different.

Images in RTE are now Processed Files. As a result
it makes little sense to store the table name of a File
since "sys_file" is the unique possible value.
The change-set removes attribute "data-htmlarea-file-table"
from the RTE, e.g.:

To comply with complex CSS frameworks like Twitter Bootstrap, we need
to add multiple classes on the same element. This adds complexity for
authors. With this new dependency feature, users just have to select
one style instead of many styles.

The syntax of this new property is:
RTE.classes.[ *classname* ] {
.requires = list of class names; list of classes that are
required by the class;
if this property, in combination with others, produces a
circular relationship, it is ignored;
when a class is added on an element, the classes it
requires are also added, possibly recursively;
when a class is removed from an element, any
non-selectable class that is not required by any of the
classes remaining on the element is also removed.
}

Using ADOdb, the charset might not be set properly, since every
database driver needs to define their own "SetCharSet" method. Every
driver extends from ADOConnection. "SetCharSet" of this class just
returns FALSE.

AbstractPlugin serves as a base for non-extbase plugins.
In order to allow for a notice free environment and no code warnings
within TYPO3 CMS AbstractPlugin should:
* provide a central property for Database access (DatabaseConnection)
* provide a central property to access GLOBALS['TSFE']
These properties will then aid both us in the CMS core development as
well as extension authors by supplying code completion in IDEs like
PHPStorm or alike.

EXT:rsaauth has several minor flaws codewise that make
PHPStorms inspection go wild:
* Clean up direct usage of $GLOBALS[TYPO3_DB].
* TCA of tx_rsaauth_keys is not needed and can be removed, as a
result, "Oops! You should not see this" no longer shows
up in db_lowlevel.

Currently registering the exception handler is done
after extensions are loaded to allow extensions to
modify configuration to override the exception handler
defined in LocalConfiguration or DefaultConfiguration.

Registering the exception handler so late has however
the drawback that exceptions throw before, lack proper
handling (and maybe in production even disclose more information
than needed).

Change that and register error handling much earlier
in the bootstrap so that exceptions thrown e.g. while
loading ext_localconf.php can show a proper stack trace
to give developers more useful information why the exception occurred.

To still allow extensions to override configuration,
we now remember the early exception and error handler classes
and potentially register a new exception handler after extensions
have been loaded.

The timestamp handed to the date function must be of type int
otherwise a warning is issued. Cast the value to int before
passing it to the date function. The important scenarios are
when the timestamp is "0" or "" (blank string).

If adding new content elements in Web>List with the CE wizard,
you get the old column layout & titles even if you have a complete
backend_layout working.

But for Moving Elements the Backend Layout is already correct.
Column titles are already in $tcaItems a few lines before
the lines in the patch for File PagePositionMap.php. Using this
values the backend_layout is correct in Web>List CE Wizard.

Since the Core uses and embraces the usage of short data type names
like "bool" or "int", internal type checks must ensure these are
recognized as well.

This patch takes the load off the checks and implements type conversion
for these short names right into the ReflectionService, so the checks
are still done against the full names like "boolean" or "integer".

Browsers started to distinguish how opening a new window
from JavaScript happens. They track "user initiated"
opening and not user initiated opening and behave differently.

A request to open a window by JavaScript which is not
user initiated is caught by a pop up blocker most of the time nowadays.
This means a user must explicitly allow the current page to
open new windows by JavaScript.

Additionally some browsers (e.g. Chrome) always open a new window
instead of a new tab if the request is not user initiated, regardless
of browser settings, which nowadays default to open a new tab.

The "save and preview" button currently initiates a page reload
which saves the document and add some JavaScript to to open a preview
window in the HTML response of this action.
This JavaScript action is then not considered to be user initiated any more
as opening the new window does not follow a direct user click action.

The result is, that if a preview window/tab was opened previously, then
the preview/window tab is just reloaded with the new preview URL.
If it is the first time the window/tab should be opened this request
is caught by the popup blocker.

Other preview buttons in the backend (from Click Menu or action toolbar)
behave differently (correctly) as they are always identified as user initiated.

For that reasons, change the "save and preview" button to directly
open a new window on click (without URL) and let the HTML/ JavaScript response
set the correct preview URL after that.

By doing so we gain a consistent behavior no matter what preview button a user
clicks first.
The only downside is, that in case the preview window is opened
the first time, it remains empty until the page is saved and then reloaded
through the JavaScript code that is already present.

When having a suggest wizard inside a flexform on a
new content element edit form, we have the problem that
we can't load the wizard's config in the AJAX request due
to missing record information. We don't know what flexform
definition to load, as we don't know what ctype is requested.

Two possible solutions exist:
- Generate the blank record again in the AJAX request, which
means we have to copy lots of code from the DataPreProcessor.
Moreover we would still need to pass the defVal GET parameter
of the EditDocumentController to the AJAX request handler
somehow, since we need that information in the DataPreProcessor
to generate the correct dummy record.
- Push the record to the AJAX request as serialized array