Camera mount sensitivity to movement in the area associated with IIET Ticket 11931.

*A* way to recover from a green camera move: (excerpt from LHO aLOG 45696):
   - reverting the ITMY, ETMY and TMSY alignment (via moving sliders and steering to top mass OSEM values) to the last time the green arms were locked (yesterday, Dec 4 2018 @ 10:00 UTC), 
    - with ISC_LOCK set to INITIAL_ALIGNMENT, (and thus ALIGN_IFO already in SET_SUS_FOR_ALS_FPMI), set ALS_YARM to LOCK_NO_SLOW_NO_WFS and confirm that the transmitted power in the YARM is above 1.0
    - while confirming the the camera loops are OFF (using your favorite method, today we chose to hold the outputs of the camera loop filters at 0.0), set ALS_YARM to INITIAL_ALIGNMENT. This turns on the green WFS, but forces a zero to the control output of the camera servos (even though it looks like they've been turned on by the guardian.)
    - wait for the ALS WFS error signals to converge toward oscillating around zero with small amplitude. Accept that the camera loop error signals are large, and request GREEN_WFS_OFFLOADED
    - move on with the rest of initial alignment.
As such, aligning MICH was a little more difficult, and aligning the SRC was more difficult.
With this path forward, we'll not know that we have a good alignment -- and PRMI/DRMI lock acquisition will be more challenging -- until we *get* PRMI/DRMI locked, start running *red* WFS, get through the CARM reduction, get the arm HARD and SOFT loops engaged. Once we get the full red ASC systems running -- then we'll be sure to check the green camera offset settings and confirm that this was indeed the cause of our problems.

NOTE -- AS OF JUNE 2019, WE ARE USING AN AUTOMATED INITIAL ALIGNMENT SEQUENCE. THIS MUST BE TURNED OFF FOR SUCH A RECOVERY. (These instructions were written before we had the automated system. We'll take notes for how we recovered today, and post later.)