hrtimer: Don't drop the base lock when migration during isolation

The current code drops the base lock and wait for the running
hrtimer's expiry event to be processed on the isolated CPU.
This leaves a window, where the running hrtimer can migrate
to a different CPU or even get freed. The pinned hrtimers that
are maintained in a temporarily list also can get freed while
the lock is dropped. The only reason for waiting for the running
hrtimer is to make sure that this hrtimer is migrated away from
the isolated CPU. This is a problem only if this hrtimer gets
rearmed from it's callback. As the possibility of this race is
very rare, it is better to have this limitation instead of fixing
the above mentioned bugs with more intrusive changes.

Change-Id: I49bd79ced8d593a084ded1aefed648d5f9e83199
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
[markivx: Forward port to 4.14, fix header include merge conflict]
Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org>
[satyap@codeaurora.org: Port to 4.19 and fix merge conflict]
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>