Change the message bit decoder

Change (and hopefully improve) the Message bit decoder.

When decoding bits, a "0" is encoded as (m[j]<m[j+1]), and a "1" is
(m[j]>m[j+1]) . However, there is a problem if mpj[ == m[j+1] because we
can't decide what it's supposed to be.

Antirez's original code defaults to a '1', and then lets the bit error
detection code sort it out. I *think* it's better to default to '0'
because it's more likely that noise added to the signal will produce a
spurious '1' rathar than anything subtracting from the signal to produce
a spurious '0'

Also, Antirez''s code only looks for errors in the first bit of the
message. I don't know why  this is.

There is a potential problem in deciding the message length if there are
any errors in the first 5 bits decoded, because this defines the message
type (the DF-??), and it's the DF that determines how many bits the
message shall contain.

If there is an error in the first 5 bits, then we could ignore the DF,
and continue decoding a long format (112 bits). However, for weak
signals, if the message is a short one (56 bits) this results in the
sigStrength decaying to the point where it's level drops below squelch,
so we discard a possibly decodeable 56bit

However, if we assume it's a short message, and only decode 56 bits, and
it's really a long message we won't have decoded all the bits.

Not sure what to do about this
Try to correct single bit errors in the DF field

If noist/sampling/Nyquist errors cause bit detection errors in the DF
pare of the frame, then we may not be able to work out the correct
length of the message. We have to guess whether the bit should be a 0 or
a 1.

In such circumstances we assume the message length is long(112 bits)
However, if we start to get encoding errors after bit 56 the we attempt
to change our original guess at the bit, and invert it. If this change
of guess would have resulted in a short message, and if the short
message would have been error free then we can recover.