Move service logic to kernel

[bakura10]

(Needs this one to be merged too: ensemble/EnsembleKernelDoctrineOrm#3)

Hi Jurians,

I'm not using Ensemble yet, but I just reading the code as I may need it for my next project.

This PR brings more flexibility based on what I've did on ZfrForum when you need to support multiple adapters, which is the case here - DoctrineORM and Zend\Db, maybe MongoDB in the future... - (see my blog post here : http://www.michaelgallego.fr/blog/2012/10/23/flexible-multi-db-adapter-architecture-for-generic-modules-in-zf-2/).

Basically, this PR allows to move all the logic of services to Ensemble\Kernel, so that you won't need to duplicate all the code in Ensemble\KernelDoctrineOrm, Ensemble\KernelZendDb, Ensemble\KernelDoctrineMongo... which would have been the case with the current architecture.

Instead, a mapper which is defined in Kernel is injected directly to the service, and methods in service call the mapper. So when using KernelDoctrineOrm, the key "Ensemble\Kernel\Mapper\Page" will return an EntityRepository while in will return a table gateway in ZendDb.

I also removed the interface Ensemble\Service\PageInterface as it does not make sense now. If people want to extend / replace some code of the service, they just extend 'Ensemble\Service\Page', and specify the new class under the key page_service_class.

There is one thing more : my PR adds a dependency to Doctrine\Common in Ensemble\Kernel because the MapperInterface implements ObjectRepository. Of course we can remove this dependency but I find it worth it, for two reasons :

1. First, you'll be able to use those mapper with all validators that come with DoctrineModule, as they need an ObjectRepository.
2. ObjectRepository defines functions that are nearly always needed (find, findAll, findOneBy...). Of course you'll have to define all of them when you'll write your Zend\Db adapter, but it's worth it.
3. Nearly everyone has a dependency to Doctrine\Common anyway (annotations...).