1) Fixes the problem of initiating AMControl::move() while a move is already in progress (see comment in #266).  2) Replaces the broken null-move shortcut in AMPVwStatusControl::move() with a new moveStartTolerance() check that is inactive by default.

While this doesn't solve the settling time problem in #266, it gives everyone the freedom to use AMControl::tolerance() to whatever level of rigour they want.

1) Moving while moving problem:

Allowing a new move() while motion is in progress can now be enabled/disabled on a per-control basis using AMControl::allowsMovesWhileMoving()/setAllowsMovesWhileMoving().  It is disabled by default in AMPVwStatusControl, since these devices know reliably when they are moving, and almost none support move updates while moving.
The opposite (default = true) was chosen for AMPVControl, since it is used for lots of configuration-type PVs [voltage levels, motor accel and velocities, etc.].  Without feedback, we never know for certain if these are "moving", and we wouldn't want to omit sending a move() [ie: configuration command] because we think it's allegedly moving.

One consequence is that AMControl::move() had to be changed to return false if there was an immediate failure; emitting moveFailed() is now reserved for failures after the move() function is done.

2) AMPVwStatusControl::moveStartTolerance() provides an optional way of handling null moves for controls that do not send state changes in this situation.  By default (moveStartTolerance() == 0), moves are always sent to the hardware and handled as normal.

A "null move" is a move to the current position (or something very close to it).  Some controls may not change their move status on a null move; in this case, the move would appear to fail, even though the control "reached" its target. This provides an optional work-around: if moveStartTolerance() changed to non-zero, and the current feedback value() is within moveStartTolerance() of the setpoint, a move() command will start and succeed immediately without any physical motion.  Note that the hardware is NOT told to move in this mode. (It if was, any move status change might be interpreted as the end of a subsequent move.)

==================

Updated all calls to move() to account for the change from emitting moveFailed() to returning false:

AMBeamlineControlMoveAction:
	Updated: move() failure calls onFailed(), with the same timing the moveFailed() signal would have.

AMControlMoveAction, AMControlMoveAction3:
	Updated: move() failure calls onMoveFailed(), with the same timing the moveFailed() signal would have.

CLSBiStateControl: updated move(), open(), and close() to check for already moving, since these controls cannot accept moves while moving.
TODO: Shutters/valves: Test out sending moves while moving...

AMDacqScanController,
SGMXASDacqScanController,
VESPERSEXAFSDacqScanController:
AMControlSet, AMControlState:
REIXSXESMCPDetector:
CLSAmptekSDD123Detector:
CLSCAEN2527HVChannel:
CLSMAXvMotor:
CLSOceanOptics65000Detector:
CLSPGT8000HVChannel:
CLSPGTDwellTimeCoordinator:
CLSSIS3820Scaler:
CLSSynchronizedDwellTime:
CLSVariableIntegrationTime:
SGMAddOnsCoordinator:
SGMBeamline:
SGMMAXvMotor:
SGMMCPDetector:
VESPERSBeamline:
VESPERSEndstation:
VESPERSExperimentConfiguration:
VESPERSMonochromator:
VESPERSPIDLoopControl:
VESPERSRoperCCDDetector:
VESPERSSampleStageControl:
SGMSampleManipulatorView:
VESPERSBendingMirrorsView:
VESPERSMotorView:
AMBasicEnumControlEditor:
AMControlEditor:
	no checking for any moveFailed()

REIXSSpectrometer:
	updated for move() returning false.
REIXSXESSpectrometerControlEditor:
	updated for move() returning false.
REIXS: enables allowsMovesWhileMoving() for REIXSHexapod.
Minor doc update in AMPVControl.h
Removes moveInProgress_ from definition of isMoving() for CLSBiStateControl, to ensure that if moveInProgress_ gets stuck on, future moves will still complete (even if it doesn't allowsMovesWhileMoving()). The status checker provides the reliable indicator if it's in the transitioning state.
CLSMdriveMotorControl: adds moveStartTolerance() of 5 microsteps.
REIXS: Fixes :sp and :fbk for MaxVMotors in REIXSBeamline; these were messed up during a merge.
Merge branch 'master' of github.com:acquaman/acquaman

Conflicts:
	source/beamline/AMControl.cpp
	source/beamline/AMControl.h
	source/beamline/AMPVControl.cpp