reduce use of properties for functionality covered by methods

[artmeln]

I think the relationship between method calls and properties is confusing and can be improved in a future version of MM. Here are two examples that illustrate my point:
- using a minimal (no properties defined) XY stage adapter, there is no way to define position limits. To set limits, one has to create corresponding properties ("PositionX" and "PositionY") but these names are not standard. As a result, any script that looks at position limits may not be fully portable.
- a minimal adapter for a 1D stage device does not allow setting the position of this device from the GUI. To get access to the stage position, I have to create a corresponding property which again can have any name making scripts not portable.

Perhaps, a stricter set of guidelines for implementing a new adapter would be useful, something along the lines of:

1. Implement all methods (including GetLimitsUm, Move, etc) even if they simply return DEVICE_UNSUPPORTED_COMMAND. [All of these methods should be exposed at the wrapper level]
2. When implementing a device adapter, avoid creating properties with functionality overlapping with existing method calls (such as PositionX for XYStage);
3. If properties are created, use names from the list of existing property names whenever possible. Such a list already exists in MMDeviceConstants.h but perhaps it could be formally maintained and made visible to the wrapper layer as well.

[nanthony21]

I agree this is an area that needs addressing. Micro-Manager has various "keyword" properties which in some cases are required in order for proper functioning of the GUI. Any required properties should instead just be part of the MMDevice interface.

As mentioned in #16 there is at least one property that is required by camera device adapters in order to work in the GUI. This is the "Binning" property. Even though the device interface allows for getting/setting of binning it doesn't allow for querying the possible String values of binning, this is what the GUI requires the property for.

[nanthony21]

2. When implementing a device adapter, avoid creating properties with functionality overlapping with existing method calls (such as PositionX for XYStage);

I've noticed that many cameras have an Exposure property even though this is part of the device interface. Part of the reason for this is that the getExposure method is defined as const which prevent member variables from being modified inside of the implementation. Device adapters can work-around this issue using the Exposure property. We should evaluate all const methods to make sure there is a good reason for them to be defined as such.