Immediate and delayed executors unification

A ScheduledExecutorService *is* an Executor, so we can use the same to
avoids to create too many threads.

The execute(runnable) method becomes a particular case of
execute(runnable, delay), with delay=0.

As the user can change the executor, delayed executions are not
supported if the given executor does not support scheduling.

This unification paves the way for adding serial execution feature.
Serial execution in background feature

Adds an optional serial attribute to @Background:

    @Background(serial="some_id")

This idea comes from #309:
https://github.com/excilys/androidannotations/issues/309

The principle of this implementation is to keep a separate queue for
each serial identifier, and to give each task to the (unique) executor
only after the previous task with the same serial identifier (if any)
has completed execution.

It guarantees that all tasks with the same serial identifier will be
called in the order, one at a time (but not necessarily on the same
thread).

It is still compatible with the delay attribute. For example:

    @Background(serial="some_id", delay=2000)

executes the task in background after at least 2 seconds *and* after the
previous task requested with serial="some_id" (if any) have completed
execution.
Test for @Background(serial="some_id")

Test if actions are sequential as expected.
Comment typo fix
Use SystemClock.sleep()

Avoid try/catch InterruptedException of Thread.sleep().
Add a @OptionMenuItem annotation to inject MenuItem
Print an error if we annotate an android MenuItem in a SherlockActivity and vice-versa
Add unit tests for processing errors with android MenuItem used in a SherlockActivity and vice-versa
Better task manager implementation

The previous implementation used a set for serial running and a map of
lists of tasks for managing the serial queues.

In practice, there will be very few parallel tasks, using maps and
creating/destroying lists is complex and unefficient.

A better approach is to use only a list of tasks (only the ones we need
to keep, having a non-null serial) and run through it sequentially for
retrieving tasks.

Moreover, it is more general, and paves the way for adding a task
cancellation feature.
Factorize surround with try/catch generation

Extract the surround-with-try-catch part of the anonymous Runnable
generation, in order to reuse it for generating other anonymous classes.
Directly generate Task instantiation

Instead of create a new Runnable instance which will be wrapped by a
Task instance, directly create a Task (which is a Runnable).
Cancellable background tasks

Adds an optional id attribute to @Background:

    @Background(id="some_id")

The user is able to cancel all background tasks having a specified id:

    BackgroundExecutor.cancelAll("some_id");
Tests for @Background attributes

Tests the serialization and cancellation of background tasks.
Do not fail if cancellation is not supported

If the executor is replaced by another not supporting cancellation (not
extending ExecutorService), it failed the first time a task with a
non-null id was requested.

Now, it just warns during cancellation.
Add an annotation to load default value for preferences from Android's resources
Fixed NPE when converters are not defined in the @Rest annotation
Merge pull request #593 from excilys/398_NPEWhenConvertersNotDeclared

Fixed NPE when converters are not defined in the @Rest annotation
Merge pull request #567 from excilys/560_MenuItem

Add a @OptionMenuItem annotation to inject MenuItem
Merge pull request #581 from excilys/536_PrefsDefaultRes

Resource injection for SharedPreferences
Comment bugfixes