Get rid of sfSearchPlugin
Store ES cfg and mappings in {search,mapping}.yml

I thought that storing ES client and server settings plus mappings
in YAML files would make things more maintainable following the
schema.yml model used in Propel.
Cleanup QubitSearch class

We are not using all the code related to ZSL anymore, but I'm
keeping the class as a singleton that creates the arElasticsearchPlugin
object. It could be extended to deal with other classes.
More search code refactoring

Moved lib/QubitSearch* classes to lib/search/* and added QubitSearchEngine,
an extra layer for better interaction with different search engines. In our
case, arElasticSearchPlugin, but others could be implemented. QubitSearch is
the factory, see getInstance().
Add skeleton for search:populate
Load Elastica with autoload.yml
Stop using sfConfigHandler to load mappings

I created arElasticSearchMapping to parse the yaml file, inspired
by sfPropelDatabaseSchema.
Add sf task to manage plugins
Add skeleton for ES entity wrapper classes
Cosmetic changes. Load wrappers.
Delete --skip option from populate task
Separate QubitAcl in smaller classes

QubitAclSearch contents ACL search filter for elasticsearch.
Drop search query from the homepage
Use new API method delete()
Make QubitSearchEngine an abstract class

I'm still unclear on the purpose of QubitSearchEngine. I'd like to
define a number of requirements and some basic funcitonality like
logging for search engine implementors (like arElasticSearchPlugin)
but I don't know if the extra work is worth it. Anyways, an abstract
class seems to fit better than an interface in this case.
Add skeleton of new ES type: accession
Add some search methods needed
Make the index property public

By doing that, we are allowing other parts of the application
to interact directly with the index object (Elastica_Index) and
that's the plan to have direct interaction with the Elastica API
from the actions.
Acommodate QubitAclSearch to Elastica API
Use new QubitAclSearch filter methods