New feature: collection engine

[ Feature description ]

An obsidian collection is a list of JSON documents, with CRUD
capabilities.

This is intended as the main storage engine for applications.

[ New class: Collection class ]

Offers CRUD capabilities to interact with documents.

This is an abstract class. Classes extending it must override:

 * public abstract function add (CollectionDocument $document);
 * public abstract function delete ($documentId);
 * public abstract function exists (CollectionDocument $document);
 * public abstract function update (CollectionDocument $document);
 * public abstract function get ($documentId);

And can also override (but that's already available):

 * public function set (CollectionDocument $document);

The generic implementations of the Collection are optimized for a
NoSQL mode.

[ New class: CollectionDocument ]

This represents a JSON document, independant of the collection
storage mean.

This class is intended to be inherited by applications, to implement
the model logic.

[ MongoCollection main storage implementation ]

MongoCollection uses MongoDB to store collection.
A MongoCollection matches a collection in the MongoDB vocabulary.

Two configurations mode are offered:
 - Each workspace has its database.
 - Each collection is prepended by the workspace name.

[ Fallback implementation: FilesCollection ]

For the case when MongoDB isn't available, we offer a filesystem
implementation. A collection is stored in a subdirectory, indicated
explicitely by path in the collection configuration block of the
workspace configuration document. Each document is stored in a file,
the document identifiant as name, .json as extension.

[ Unit testing ]

Full unit testing code coverage for FilesCollection.

CRUD features unit testing for MongoDB, all methods are covered.

Independant checks of how data are stored in the MongoDB collection
could be added (by independant, we mean direct MongoDB checks, without
relying on the CRUD Collection methods).

[ Others changes ]

* To ease unit tests invoke, autoload now uses absolute path, and not
relative to root folder. Of course, this absolute path is determined
at runtime relative to the current folder.

* Updating README to fix newlines and add unit testing instructions.