trickle: separation of rpl and trickle

This PR introduces trickle as an independend module.
Currently, trickle is interleaved with rpl, which means that
trickle is not usable by other protocols than rpl.
Trickle's implementation would not work properly even for rpl if multiple dodags
were used, since it is only possible to initialize just one trickle
timer.

In this PR I introduce a `trickle_t` struct holding the state of one
trickle timer. Thus, it is possible to initialize several trickle
timers, each for one dodag or even for other protocols than rpl.
The function and the appropriate arguments to be executed by trickle periodically
are passed in a generic way through an `trickle_callback_t` struct, holding the function pointer and the arguments.

The trickle module defines a set of functions and structs to modify a trickle timer,
**but** does not has its own thread. This means, that in order to use trickle, you have to provide a thread for trickle. Note, that this can also be your application's main thread.
Trickle interacts with your thread via the vtimer_api, especially *vtimer_set_msg*,
so it is imperative to have a looped msg_recv in your thread.

RPL specific changes:
I moved the code for the routing entry updates and the DAO handling out of the trickle.c file. In this PR, the RPL/trickle stack has only two threads, the main RPL thread *rpl_process*, which receives ICMP messages from the ip layer and *rpl_update_process*, which handles the routing entry updates, DAO transmissions and the trickle updating.