Only use 16 significative bits for MSP430 hwtimers

Rationale: using 32 significative bits on MSP430 (which only have 16-bit HW timer counters) implies the use of timer overflow interrupt to manage correctly the 16 MSBs (most significant bits) of the counter. However, since <code>hwtimer_spin()</code> can be executed from interrupt handler -- that is: with IRQ disabled -- it is impossible to handle correctly these 16 MSBs in every case. The race condition where timer overflow occurs when <code>hwtimer_spin()</code> runs with interrupts disabled -- thus provoking a deadlock -- is one of the causes of the failure of hwtimer_wait test on MSP430 (see issue #426).
Consequently, I propose to only use the 16 bits of the hardware-managed timer counter: this solves every reliability issue strictly related to hwtimers.
Inconvenient: it becomes impossible to set an hwtimer with an offset of more than 65535 ticks -- that is: 2 seconds on our platforms. But I think it is neither needed nor possible to handle waits of 2 seconds or more on MSP430 platforms with hwtimers (it should be still possible to handle such long waits with less precision with the vtimers, though).

Together with #1618, it should fix the reliability problems that plague the ports of RIOT on MSP430 platforms.

~~Depend on #1617~~
Well, we return an unsigned long (32-bit value on MSP430), to follow hwtimer API.

This bitwise AND tells the compiler to zero out the 16 most significant bits during the transtyping 16->32bit. If GCC is clever, this could/should translate to a NOP; otherwise, it's just an atomic operation on a 16-bit register (i.e.: only one machine cycle).

Maybe I'm paranoiac here, but with all the problems we've had, I prefer to be on the safe side.