First attempt at adding labels to Ecrire.

This is in relation to #47 and it's almost complete. The tests are
missing, however.

I have chosen to use 'label' as the name for the tag system in Ecrire.
I believe this is more relevant.

As for what this commit brings to the table, here's the low down:

First, it brings a new two new models to the database: Label and
Property (The migration name is a little bit fucked but I will merge all
those migration before 1.0 so there will only be 1 migration per model
to start with fresh migrations).

Property is a HABTM model with polymorphic attributes, you can attach
any type of object to a Post. I'm not a huge find of this method however
as this brings a lot of complexity for very little gain. I always wanted
to play with the JSON type in (implemented in Postgresql 9.2) and I believe this would be
ideal. The controller however is solid so I think it's a good step
forward. The controller let you create and destroy new property on a
post (like a key-value store).

Now, you can only create label via this controller. Actually, more I'm
writing about this, more I'm thinking I should straight up start using
JSON type because it's fucking awesome and HABTM fucking sucks.

So long, and thanks for all the fish.
Removed pg_search as I'm not using search anymore. List FTW
Merge branch 'master' into labels
Moved to H TO THE STORE

This is a change in the migration where I removed HABTM and moved toward
the Hstore data type with postgresql >= 9.2

Now, the labels are saved in a key value store where the ids are joined
in a string
Removed unecessary routes

PropertiesController is now accessible via a singular resource. Because
the properties are set in Hstore, they won't have any ID as we know it.
The only thing that is necessary is the post id
This is the essence of the new Hstore properties

The decorators, views, models and controllers needed to be refitted to
be able to handle the way Hstore do its thing.

One thing that is awesome with this change is that Hstore will be able
to store arbitrary data (Theme customization & storage, yay!)

First version of this is you can register a new class to a new property.
Then, you need to have that property bound to a model (usually under the
Property namespace)

When the controller will receive a POST or a DELETE, it will look at the
requested property and instantiate that class. It will then call
[create|destroy] depending on the requested action.
Simplified the process of getting labels for a post
Removed Admin::Label as it brought confusion

Admin namespace should only be used by record that need extra
configuration/security. Labels do not
Used new labels accessor on Post
Use ::Label instead of Admin::Label
Fixed tests not loading Ecrire and fixtures

Two errors are fixed here:

- Ecrire wouldn't be able to load properly because
  Ecrire::Railtie.configured? is asked when Railtie is loaded as a
  class. This means that maybe I will have to change the way I include
  the modules in Railtie. An idea ->
  http://stackoverflow.com/questions/4943055/ruby-use-module-include-in-instance-method-of-class

- The fixtures were not loaded because it looks for a relative path to
  Rails.root. since the root is pointing at the default theme, it
  wouldn't play nice. This is a normal method so that change is good
Migrate before testing & Tests coverage for labels