Cancel current vibration asynchronously in VibratorService

The vibration is now played asynchronously by the VibrationThread, but
cancelling the current vibration before playing a new one (and turning
off the vibrator HAL) is still being done synchronously in the vibrate
method.

This change makes that step also async, handled only by the
VibrationThread.cancel method. The new vibration is only started once
the previous one has completely finished.

Other fixes:

- Cancelling a vibration and playing another one in sequence was causing
the second one to be interrupted by the VibrationThread asynchronous
cancellation (cts for multi-thread was flaky). Now the service is only
starting the second vibration after the first one was completely cancelled.

- VibrationStep was waiting for the entire callback timeout to finish
instead of finishing early after native callback (see vibration async
trace with duration >100ms in b/178179597 perfetto traces). It is now
waiting on a boolean condition instead, to follow the Object.wait
documentation.

- Using a mLock object explicitly to synchronize, wait and notify in the
VibrationThread, instead of using the thread outer instance.

Bug: 178179597
Bug: 178029288
Test: VibratorServiceTest
Change-Id: Ied88e6790019a8c174a25e75f29870793e993a78