VESPERS: Added some extra beamline information to the scan notes.  It's general beamline info that doesn't belong in the scan configuration but requires a little more text then in the scan initial conditions.
Discovered an inconsistency in how I set the values in the CLSSR570 class.  It has been rectified, but a lot of classes needed to be updated.  Tests showed no change in performance.  VESPERS: Added some more general information to the scan notes section.  Made the VESPERSWorkflowAssistantView visibility accurate (only show up for XAS).
Merge branch 'master' of github.com:acquaman/acquaman
VESPERS: Added a SMAK exporter for VESPERS data.  It isn't general because it needs some VESPERS specific things.  Also found a bug in the config file for 2D-hv-4Elem where it was putting the horizontal position in both x and y columns.
BioXAS: Create BXMAppController, BXMMain, BioXASMainAcquaman.pro
Test programming for BioXAS side endstation
Merge branch 'master' of github.com:acquaman/acquaman
Merge branch 'master' of github.com:acquaman/acquaman
VESPERS: Finished the SMAK exporter when using the four element detector.
Merge branch 'master' of github.com:acquaman/acquaman
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' into dataStoreUpgrade

Conflicts:
	source/beamline/REIXS/REIXSBeamline.cpp