Modifications on Server Resource and Hydrator

This commit provides some extra features and improvements:

While creating a REST service for Doctrine ODM (for MongoDB), I bumped in some problems. Maybe it is a good idea to make this repository fully Doctrine compatible (ORM, ODM, ...).
I also noticed that the hydrators and ODM are not configurable in the module configuration, like the rest of the Apigility API.

So here are some extra features:

- Use the doctrine hydrator by default

- Make resource and hydrators configurable. (In ODM there is an option to generate custom hydrators which allow schema migrations by default). Default fallback to doctrine hydrator when not set.

- Allow the resources to be configurable (hydrator, ObjectManager)

- Make the Resource compatible with ODM. e.g. The queryBuilder is not compatible with ORM, so I used findBy instead, which limits the query posibilities. On the other hand: non standard queries could always be created in the repository by overwriting the findAll method in the resource.

- Renamed the classes to a more readable name when using namespaces.

Example classes in the API Rest folder:
Collection - no changes:
```php
<?php
namespace FileSystemApi\V1\Rest\Assets;

use Zend\Paginator\Paginator;

class AssetsCollection extends Paginator
{
}
```

Resource: fully extendable
```php
<?php
namespace FileSystemApi\V1\Rest\Assets;

use SoliantConsulting\Apigility\Server\Resource\DoctrineResource;

class AssetsResource extends DoctrineResource
{

}
```

Hydrators: No custom classes required because it is fully configurable.

Configuration:
The zf-rest entity should have link to the doctrine entities / documents:
```
'entity_class' => 'FileSystem\\Entity\\Asset',
'entity_class' => 'FileSystem\\Entity\\Directory',
```
Other sample configuration can be found at:
```
soliantconsulting-apigility/config/doctrine-objects-sample-config.php
```

This commit only includes the Server files. Currently I do not have the time to adjust the Admin and Client objects.
Normally this should be pretty straightforward.

I hope to retrieve some feedback, because I think this is a step in the right direction for the module.