… to modify the type of a staged layout

…CM Template administration

… once

…ugins at once"

This reverts commit 3e85b40.

…estination

…al-impl (Needed to start the portal bundles)

…point to the bundle directory

…dmin.

…e groupId when neccessary

…d properly as plain text.

… to render

…e from the listener and put all the logic in a rule

…oes not use the listeners (as in the new OSGi apps) will need to declare the rule by themselves

…n based auto cleanup in order to make the test run faster

Currently, only the LiferayRepository supports the trash bin, but it does make
sense for other kind of repositories to support it. By representing the Trash
functionality with a capability we avoid polluting the repository interfaces
with methods that only a small subset of repositories actually need, still
allowing those that need it to implement the capability.

Move trash related code from DLAppHelper into the new capability:

  - DLAppHelper.deleteFolder -> TrashCapability.deleteFolder
  - DLAppHelper.deleteFileEntry -> TrashCapability.deleteFileEntry

For the moment, the other methods simply delegate into
DLAppHelper. Eventually, all callers of DLAppHelper trash methods will
be modified to use the capability, and those methods will be removed
from DLAppHelper.

Move code shared by local and non-local factories into the base class.

Change method names to use a more precise terminology:

  - Internal repository (was Liferay repository): repository
    implementation provided by Liferay.

  - External repository: repository implementations backed by other
    products (e.g. Alfresco, Documentum, etc.).

…y tests

Use the capabilities to execute trash logic. Also, instead of testing for
concrete classes to check if features are supported, use CapabilityProvider
`isCapabilityProvided` method.

Replace direct calls to dlAppHelper with capability uses. Also, insert
a capability use after each call to dlAppHelper.delete(File/Folder) (we need to
do so as we removed trash handling code from dlAppHelper).

Inside the trash capability we have to invoke DLAppHelper to keep
everything working. This ugliness is temporal: in the short term we'll
develop a repository event system, and capabilities will be able to
register listeners to execute when particular operations are executed.

As we move more code into capabilities those calls will be removed from
here and invoked through repository events. In this case, the trash
capability will be able to trigger a "file deleted" (or "folder
deleted") event that will execute all the additional logic.

Move all the complexity into the trash capability.

When deleting file entries or folders, invoke the trash capability
explicitly.

Note that in the short term we will remove this hardcoded logic and
create an event system around core repository operations (CRUD over file
entries and folders basically). We'll move this hardcoded code into
event listeners and remove the `deleteTrashEntry` methods from the
interface.