LPS-47511

Hey Brian,

This is the initial commit to support capabilities on different repositories.
The capabilities will decide if repository supports trash, assets, liferay sync, preview... in a more decoupled way. 

Thx!

You can see more from @adolfopa here:

The DL supports a wide range of functionality (permissions, assets, sync, etc.) where some of it is only available for Liferay repositories, while other may be applicable in general. The way this extra functionality is managed right now has a some problems:

- Everything is hardcoded in the DLAppHelper class.
- Coarse granularity: there is no way to support diferent subsets of functionality. You must support everything or nothing.
- Not extensible: the choice of when/where to execute these extra actions is done by checking for concrete classes with "instanceof". This makes any extension effort extremely difficult.
- Heavy code duplication between DLAppService (Repository) and DLAppLocalService (LocalRepository). With the exception of permission checking, they are almost identical.

To solve all this problems we introduce the concept of a repository "Capability". A repository has a core functionality (storage, and nothing more) plus a set of additional capabilities (assets, sync, permissions, etc.). With this approach, we will be able to combine different "core" repositories (LiferayRepository, CMISRepository, etc.) with different sets of capabilities depending on the circumstances:

- To save attachments, LARs, etc. we would use a LiferayRepository with no capabilities.
- For the DL, we would use a repository with all capabilities.
- Different external repositories may support different capabilities (e.g. we could implement a `PermissionCapability` for Alfresco using their propietary API).

Additionally, this will allow us to get rid of the LocalRepository / Repository dichotomy: simply add a `PermissionCapability` where appropriate and you're done. No duplication needed.

Capabilities will play three roles:

- Internal capabilities: a repository may support assets or sync with no need for clients to be aware of this fact (it is an implementation detail of the repository).
- Exported capabilities: in some circumstances, we may want a repository to offer extra operations to their clients without polluting the repository interfaces; capabilities offer a type-safe way of extending a repository. An example of this kind of capability is the `TrashCapability`.
- Hybrid: capabilities that will be used both internally by a repository and exported to the outside world. For example, an Alfresco repository may implement the `PermissionCapability`. The repository would use this capability internally to check permissions before any operation, but will also export it, as clients may also need to use it (to hide/show UI elements, for example).

Initially, the following capabilities are going to be considered: assets, ratings, trash bin, comments, workflow, previews, sync and subscriptions.