Unconvential functions to access velocity in Velocity Over Ground Messages

[mrksngl]

VelocityOverGroundMsg has methods getEastToWestVelocity and getNorthToSouthVelocity.
They are not incorrect per se - meaning: they do what they describe. But they are unconventional:

• normally, positive values denote North resp. East, which is not the case here
• the standard tells us that ME bits 14/25 (the direction bits) denote North resp. East (for a value of 0).
  I'm not saying that lib1090 is doing something wrong here. In fact, it uses flags direction_south and direction_west for those bits.
• if we interpret those bits as sign bits, like we do for a lot of other fields as well (e.g. vertical rate), then value 0 also means "no sign" or also "don't negate". So from that perspective, the returned value would be "negated IFF this bit is set", yet those 2 functions do the exact opposite.
• we can greatly observe the outcome of that decision in method getTrueTrackAngle(): Math.atan2(-getEastToWestVelocity(), -getNorthToSouthVelocity());. Yes, both functions are used negated. Yes, this is confusing.

I recommend deprecating those functions, add new ones which return positive values for North resp East, and let getTrueTrackAngle use the new versions without confusing negation.

At least I recommend fixing the comment

@return velocity from east to south in knots or null if information is not available

because east to south is...interesting ;)