Don't lock VibrationStepConductor state only executed by VibrationThread.

Vibration processing is now clearly isolated to the VibrationThread, with
a much smaller footprint for communicating to that. The new locking approach
is purely around the inter-thread communication footprint, which is just the
list of completed vibrators.

The main logical change is that "processVibratorCompleteCallbacksLocked"
may previously have been occasionally executed on the callback thread,
notably calling into some methods on Steps. Now the execution is strictly
performed on the VibrationThread. Importantly, this means steps don't have
to worry about threading concerns internally when processing cancellations,
and the callback processing can be centralised to the "waitForNextStep" method.

Bug: 193792066
Test: manual, presubmit
Change-Id: Id165fba768f584e75f9f67d337b2d87642764055