[FEATURE] Expand db function searchQuery to handle AND and OR constraints

The database function searchQuery can build queries for multiple search
words. But those words are expected to be all in the field. Sometimes it
is useful to use an OR constraint. So this function should be extended to
have another parameter to do so.

When e.g. installing tt_news version 3.4.0 (compatible to
TYPO3 CMS 6.0.0) a fatal error will be shown since tt_news
uses a class in ext_tables.php that requires the autoloader's
registry information.

The following happens on installing an extension:
* flushing the caches (including the class loader cache)
* redirecting to list view of extension manager
* triggering shutdown method in ClassLoader
* updating cache if $cacheUpdateRequired is set

This updates the autoloader registry with old data since
the extension's ext_autoload.php has not been considered at
that time.

The issue is fixed by explicitly reloading the ClassLoader
cache after TYPO3_LOADED_EXT has been reloaded.

The content object renderer still instantiates content objects with
tslib_content_ prefix. The patch changes this to the namespaced
class. Additionally, all content objects are now tested for successful
instantiation with additional unit tests. While creating those tests
it became obvious that the ShockwaveFlashObject content object was
named incorrectly, so this is adapted along the way.

The extbase team wants to be in sync with TYPO3 Flow
again which leads to the change of the Repository
Interface that defines three new methods one has to
implement to fulfill the interface contract. As the
AbstractRepsoitory of FAL directly uses the interface
instead of the Repository class it has to implement
these methods itself.

The file.import function can't handle file relations. Sometimes
you have to deal with uids of sys_file_references instead of
sys_file uids. One prominent case is import.data = levelmedia
This patch adds an flag to IMG_RESOURCE with that, a given uid
is interpreted as reference instead of file uid.

With 6.0 the bootstrap related core code was split into small methods
and transferred to a group of encapsulating classes.
While this is an important step to get a flexible and maintainable
bootstrap in the end, this process is not completed and still misses
for example a real concept for scopes.
The patch groups methods used in all scopes in bootstrap wrapper
methods and makes the business methods protected. The whole API and
all affected classes are marked as "internal", together with a
warning that this API will change in the future and shouldn't be
used by 3rd party code that is not under core control.
This gives freedom for future development of this core code without
taking care of backwards compatibility. With previous versions there
was no API at all, so this is not a feature loss from an extension
point of view.

Overlays for the relation fields of a page in the rootline,
introduced with the rootline class refactoring, do not work for
translated pages.
The problem is that the language overlay for the rootline is done outside
the RootlineUtility, or former PageRepository, and therefore also never
has been cached.

The drivers in FAL are capable of retrieving files recursively.
This might be sinful in some cases and custom usages. Anyhow,
the parameter $recursive is not passed up until Storage and
Folder objects. With that users are forced to work with the
driver directly.

As it is highly discouraged to work directly on the driver,
just pass up the parameter within the abstraction layers.

With 6.0 all Xclass inclusion in the classes have been
removed and registration of Xclasses have previously been
moved to the autoloader. This added additional complexity
and another concern to the class loader.

To enable extensions to override classes, an object
implementation registry is now introduced, where you
can now define which implementation class name should
be used for an original class.

This not only is a complete replacement for former
Xclasses, but at the same time adds the possibility
to have the implementation class name within the namespace
and scope of the extension which registers the override.

On top it would also be possible to register implementations
for interfaces.

Since only class names are mapped here, we again have a
clear separation of concerns, where the class loader
is only responsible to resolve paths for class names
and the "object manager" method makeInstance for resolving
the final class name to instantiate.

The path of the target class can be resolved automatically
by the class loader if naming conventions are met or the
target class name is put into the autoloading registry.

The patch splits the FLUIDTEMPLATE content object to smaller
and more readable code pieces. Additionally, 27 new unit tests
are added for the public API method, checking all important
code areas and documenting current behavior.

The jsfunc.placeholder.js file was introduced to have a fallback
for Internet Explorer on the HTML5 placeholder feature. However,
this handling is currently active in all browsers and results in
broken NULL values for textarea, since textarea don't have a
human readable representation like input fields.

Deactivated textarea elements, fields that have a NULL value
stored in the database, are not visualized correctly when
loading the backend editing form. The status is currently set
using JavaScript and triggered by TBE_EDITOR.fieldSet().
However, textareas don't have a human readable clone and thus
fieldSet() is not called and thus no status is set.

This issue is fixed by directly rendering the status in the
FormEngine.

File processing is a central part of TYPO3's file usage, as e.g. all
images in content elements have to be resized when they don't fit the
requirements. However, the current implementation of file processing
with FAL has several drawbacks and shortcomings, not to mention quite a
few bugs.

The processing to be done is described in tasks, which are part of a
ProcessedFile's properties. The processing itself is now moved to
processors, which could execute the tasks using different utilities,
e.g. ImageMagick or some cloud image processing service. Currently,
there is only a local image processor implementation, which relies on
ImageMagick/GraphicsMagick (i.e. uses the same configuration as the old
processing).

The processed file class now also supports safe handling of unchanged
files, i.e. files that should have been processed, but didn't need
processing.

Some tests fail on Windows systems. Mostly this is because of a missing
file and folder permission handling. Those tests have to be skipped.
Furthermore there is some path fixing needed in basic class.

[BUGFIX] Default behaviour for field rendering of configuration is dropped

In TYPO3 4.7 (and below) the default field of a configuration was a text
field. With a wrong configuration type in ext_conf_template.txt now the
field isn't rendered any more. There should be a fallback to a normal
input field like it used to.

The meta data (like description, title, ...) in File References
cannot be used to disable the inherited data from the parent
File object. Currently values can be blank which results in
using data from the parent. To really override by using blanks,
the new NULL feature for TCA fields needs to be used.