Avoid dividing by zero for zero sampleFreq.

I'm not entirely sure about this patch.  I know I originally wrote it because I was getting a divide-by-zero in MadgwickAHRSupdate and that was the easiest place to fix it.  But now that I look at the code, I'm not sure that it's the best place.

I think what was happening was that it was taking a while to start up (for whatever reason), and so the frequency computation code was getting triggered on the first run through psmove_orientation_update.  So then orientation->sample_freq_measure_count was still set to '0' from the initialization code, and the frequency ended up zero.

It might make more sense to initialize that to '2', or have an explicit check that it's greater than zero, or something along those lines, rather than hack around the problem in MadgwickAHRSupdate.  If we go that route it'd probably also be worth adding an explicit "if x == 0 { abort(); }" type of thing in MadgwickAHRSupdate so that we don't just silently generate NaNs and make a mess of things.

I'm submitting this as-is to start the conversation but happy to revise and resubmit based on your preference.