Refactor Camera and Driver classes

[AnthonyHorton]

SBIG, FLI & ZWO camera classes all do very similar things but in slightly different ways. Makes testing and maintenance hard, & will just get harder if more camera types do their own thing in the future.

A few things in particular:

• [x] When taking an exposure all three do some setup, then start the exposure, then spawn a thread to poll the camera and do readout when the exposure is complete. SBIG does this all in the low level Driver class while FLI & ZWO do this in the Camera class. None of them are using their own is_exposing property (recently added), instead they poll the driver method directly. This all could be made much more consistent across camera types, and much of it moved into a base class.
• [x] Likewise all of them use a Driver method to scan for connected cameras, search for one with a matching UID, then claim the corresponding 'handle' or 'camera_ID'. Again SBIG does this in the driver class while FLI and ZWO do this in the Camera class. The code is very similar in all three cases, and most of it could be made generic and moved to a base class.
• [x] More fundamentally all of them use a single instance of a low level driver class per camera type, but create that instance differently. FLI and ZWO do this simply, making the Driver a class variable of the Camera class and creating it in the Camera.__init__() if no other Camera instance has already done so. Conversely the older SBIG code does this by overriding the Camera class __new__() method. I now have no idea why I did it this way...
• [ ] More nitpicky: I want to standardise on using Python enum as the Python version of the enums in the SDK C headers. I didn't know about this module when I wrote the SBIG and FLI Driver classes they mostly use pairs of dictionaries instead. enum.IntEnum and enum.Flag are a much closer match to the functionality of C enums.
• [x] Generally speaking there is need for more consistency in the Driver and Camera class split. I want the Driver classes to be thin wrappers around the corresponding camera SDK API, with a more or less one-to-one mapping of class methods to SDK functions. Additional functionality shouldn't extend much beyond Python->C & C->Python conversion of inputs and outputs, validating inputs, parsing errors, and logging. The Camera class, conversely, should present a standardised POCS interface via its public methods and properties, and include all the logic to convert that into calls of the low level Driver methods. This is basically already the case with ZWO, is mostly true of FLI, but isn't really the case with SBIG.

Trying to work out how to attack this in manageable chunks, in a way that leaves it working at each step. Would be a mammoth PR to do it all at once.

[wtgee]

@AnthonyHorton can we close this?

[AnthonyHorton]

Some of the things on the list have been done, some haven't. I think this needs updating rather than closing. I'll get on it.

[AnthonyHorton]

#787 (and follow ups) addressed 1, 2, 3 & 5. The standardisation on enum instead of dictionaries is still to be done.

[wtgee]

Closing this issue as done/stale. Feel free to re-open as needed.