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~~
s/check/determine/
Move comment up one line please.