Custom rotor precision

[bjorgan]

~~~s/precision/resolution/~~~

Current behavior is that new position commands are sent only when round(angle) differs from round(previous_angle). This makes position updates kind of rate-limited, down to position differences of approximately 1 degree in either direction, not exactly precision or resolution-limited or time-limited. Numerical precision is kept, and the precision of the sent angle is limited by the rotor controller, not flyby. 

The commands were probably originally rate-limited in this way because rotor positioning, screen updates and keyboard input are all done in the same thread with blocking with timeout on `getch()`, which would, without rate-limiting, otherwise make rotor positioning happen more frequently if the user were to press a key.

The way this is done is not really problematic, the larger problem with the rotor controlling is that the antenna always will lag behind the assumed position of the satellite, which should be fixed by predicting rotor angles in advance.

@oyvkar had problems with a specific rotor, where it started vibrating wildly if it got position updates with angle differences of less than 4 degrees in either direction. This issue was mainly made to work around that (but also laid on the shelf for a bit since he moved on to use other tools and had other quickfixes around the problems with configuration of rotctld itself). Could still be useful to have better control over the rate-limiting. Also related to #70.

[bjorgan]

This is not a real issue, more a thing to keep in mind, so closing in favor of #76 and #70.