Move more functionality into the ADDriver base class

[MarkRivers]

The ADDriver base class currently mostly just provides parameter definitions but very few methods. This means that derived driver classes all need to implement writeInt32 and writeFloat64 to handle all parameters like ADAcquire, ADExposureTime, etc.

The base class could detect many of these parameters and call methods in the derived classes, for example new methods like AcquireStart(), AcquireStop, setExposureTime(), etc. This would simplify derived classes and make their implementation more uniform.

It would need to be done in a backwards compatible manner so that existing drivers that do not implement these methods continue to work.

One method that would be very useful would be for handling NDArray callbacks where all drivers currently need to do:
- setUniqueID()
- setTimeStamp()
- setAttributes()
- callPlugins()
A method that does all 4 of the above steps, plus more in the future would be very useful.

[ulrikpedersen]

I've been thinking about this as well. In order to provide a new and simpler interface to write new drivers/plugins against - but without breaking all existing drivers, we could consider an Adaptor pattern. See for instance section 3.4.2: http://www.apibook.com/Chapter_3.pdf

That way we can retain the old interface and provide a new one. Over time we can then move drivers to the new interface and eventually retire the current one.