KIE Persistence cleanup for creation of other architectures

In order to have clean implementations of other types of persistence not related to JPA, we need to move a lot of the interfaces that now live in drools-persistence-jpa and jbpm-persistence-jpa to a place where they don't depend on JPA at all. It involves a set of modifications:

• Creating drools-persistence-api and jbpm-persistence-api: Right now, some of the persistence components and interfaces are only in the JPA projects, where they should be reusable from other persistencies. We should refactor these projects to reuse these interfaces without having the JPA dependencies added each time we do so.
• SingleSessionCommandService small refactor: The current command service is very tied in the implementation to JPA. There should be a discussion on whether to create different command service implementations for other persistence mechanisms, or refactor the current SingleSessionCommandService to work with different models.
• PersistenceContext and ProcessPersistenceContext refactors: Current interfaces of PersistenceContext and ProcessPersistenceContext are dependent on the JPA implementations of the model (ProcessInstanceInfo, SessionInfo, and WorkItemInfo). In order to work with other persistence mechanisms, it should be refactored to work with the runtime model (ProcessInstance, KieSession, and WorkItem, respectively), build the implementations locally, and be able to return the right element if requested by other components (ProcessInstanceManager, SignalManager, etc)
• TaskPersistenceContext refactors: There are multiple dynamic HQL queries used in the task service code which wouldn’t be implementable in another persistence model. To avoid it, there should be a refactor of those methods to use a Criteria mechanism. This way, the different filtering objects can be used in a different manner by other persistence mechanisms to create the queries required.
• The way the current task model relates tasks and content, comment, attachment and deadline objects is dependent on the way JPA stores that information (relations by ID), so there should be a refactor of the task persistence context interface to do the relation between components for us. For the JPA implementation, it would relate them by ID. For other persistence mechanisms it could just add the sub-object to the task object.
• TimerJobFactoryManager / TimerService refactors: Currently the possible implementations of a TimerJobFactoryManager are bound in the construction by the values of an enum (TimeJobFactoryType). A refactor would be useful here not just for extending the existing types, but for allowing other types of timer job factories to be dynamically added in the future