Feature clock sync (gtimer and protocols: gtsp,ftsp,pulsesync) 

This PR combines the following PRs: #1428, #1427, #1426, #1425. 

Potential issues with this PR (read: semi controversial changes) :
* transceiver driver level tx/rx timestamping requires changes to the drivers (note: rx timestamping is necessary; however, the protocols will still work even if tx timestamping is not integrated in the driver)
* ~~integration in sixlowpan stack: Currently, the protocols send and receive ieee802.15.4 frames.
In order to be able to use sixlowpan and some clock sync protocols we decided to integrate the read beacon functions of our protocols into sixlowpan/mac.c.~~ In order to distinguish between sixlowpan ieee802.15.4 frames and clock sync. beacons we make use of the sixlowpan dispatch header (this approach is (AFAIK) conformant to RFC4944 Section 5.1 (look for "NALP")) .

Detailed description of the new RIOT modules in this PR:
* gtimer: a virtual clock, for clock sync. protocols, with an adjustable rate and value. This could be developed further into a vtimer like global timer module (with functions like: gtimer_usleep / gtimer_set_wakeup etc.).
Right now, gtimer's only use (from a programmer perspective) is that it returns the current global time if
gtimer_now is executed (However, nothing stops you from polling gtimer_now periodically).
* gtsp: This is an implementation of the Gradient Clock Synchronization Protocol (GTSP) described in [1].
This protocol is optimized to reduce the local error (synchronization error between nodes in a one hop radius). However it also guarantees a decent global synchronization error. It should also be noted that this protocol
is fully decentralized (no single point of failure; all nodes will agree upon the highest time in the network)
* ftsp: This in an implementation of the Flooding Time Synchronization Protocol (FTSP) described in [2]. 
FTSP is the standard clock synchronization protocol in tinyOS. There is also an implementation for Contiki.
FTSP is a hierarchical protocol which synchronizes every node against a root. Currently, a node with id=1
will always become the root. 
* pulsesync: This is an implementation of the PulseSync protocol described in [3]. PulseSync is an improved version of FTSP (faster beacon propagation at the cost of higher collision probability).

[1] Philipp Sommer and Roger Wattenhofer. 2009. Gradient clock synchronization in wireless sensor networks. In Proceedings of the 2009 International Conference on Information Processing in Sensor Networks (IPSN '09). IEEE Computer Society, Washington, DC, USA, 37-48.
[2] Miklós Maróti, Branislav Kusy, Gyula Simon, and Ákos Lédeczi. 2004. The flooding time synchronization protocol. In Proceedings of the 2nd international conference on Embedded networked sensor systems (SenSys '04). ACM, New York, NY, USA, 39-49. 
[3] Christoph Lenzen, Philipp Sommer, and Roger Wattenhofer. 2009. Optimal clock synchronization in networks. In Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems (SenSys '09). ACM, New York, NY, USA, 225-238.



Isn't 32 probably sufficient?