Make manual control trigger an unhomed state in Dome class

[fergusL]

I'd be tempted to call this is_moving as it's more intuitive, & more in keeping with the general principle of naming things after meaning and not implementation details. The only things giving me second thoughts about that are that the dome can take up to a few seconds to come to a halt after being told to stop, and that the dome could be moving because someone is in the dome pressing the handset buttons. Maybe move_active instead?

That thought about the handset raises another issue. If someone does move the dome manually then the Pi is likely to lose track of where the dome actually is. It will see the encoder pulsing, but it has not way of telling which way the dome is moving. It would just assume the dome is moving in the direction that it last told it to, which might be wrong. What should happen instead is if the encoder starts registering pulses more than a few seconds after the Pi has told it to stop the Pi should just flag itself as 'unhomed', and refuse to move the dome again until eithe rehomed or synced.

Originally posted by @AnthonyHorton in #59

[fergusL]

regarding first part, I also have a .dome_in_motion property that is based off the rotation_relay state. Maybe having a thread event in this case is redundant?