This enables defining inline guard handlers to override ones present in gems,
e.g. you could define an inline Guard::RSpec handler and have guard use that
instead of first trying to load 'guard/rspec' from the 'guard-rspec' gem.
Also gets rid of the ill-named method `try_to_load_gem`. Handlers are simply
found in the $LOAD_PATH and don't have to necessarily come from gems.
I basically went through all specs and applied the following rules:
* Use `describe` for methods and `context` for contexts.
* All class methods starts with `.` and instance methods with `#`.
* Removed all `it should`, because the specs _have to_.
* Applied a consistant naming on all listener specs.
* Make fixture usage more fail save by giving generous sleep times.
* Make all behaviour description non-technical and easy to understand.
The goal of this excercise was to have a documentation that is easy
readable and describes the behaviour and not the implementation.
Try it out by using the RSpec documentation format!
Every guard task are now executed through
supervised_task method.
If a guard failed to achieve its task(raise error)
a message is logged and the guard is fired.
The stop method now always quit the application
at the end.
Specs added. The documentation specify that if a
throw an exception, it will be dismissed.
