Add DisplayContent to hierarchy after stubbing.

doAnswer type of stubing doesn't completely eliminate race conditions.
The failure happens because when answers are commited to
InvocationContainerImpl it uses a local variable invocationForStubbing
to save the stubbing method, which could be changed from a different
thread by a natural call into the mock/spy before answers are added to
InvocationContainerImpl.

Sequence of events:
1) [testing thread] Commiting stubbing by calling method into the
mock/spy. In this case it could be
DisplayContent#supportsSystemDecoration() in line 159 in
TestDisplayContent in this case. The call was intercepted by
MockHandlerImpl#handle() and further handled by
InvocationContainerImpl#setMethodForStubbing(), in which it already set
invocationForTesting field and didn't clear doAnswerStyleStubbing yet.
2) Another thread calls into the same mock/spy regularly. In this case
it is DisplayContent#getDisplay() as shown in the stack trace in the
bug. It's intercepted by MockHandlerImpl#handle() as well and likely it
thinks we're in the process of doAnswers style procssing and calls into
setMethodForStubbing(). It then mistakenly think we're stubbing
DisplayContent#getDisplay() and found the answer we offered isn't
compatible in the return value.

This is a caveat in Mockito thread safety, though it can be fixed in
Mockito if they're willing to do so. However it's certainly a lot faster
to fix it in our test code.

Also check the caller holds global lock in lieu of synchronization
clause because caller is supposed to be in tests with
RunWith(WindowTestRunner.class) annotation.

Bug: 144611135
Test: atest com.android.server.wm.AnimatingActivityRegistryTest
Change-Id: I8cc4b6ce11ad6c205309476c9eeb4db315f558d6