Fix race from DisplayRepository.getDisplay

Before this cl getDisplay(id) was guaranteed to not cause any binder call, as the mapping between displayId and Display in DisplayRepository was done in the background.

However, this was causing getDisplay(id) to possibly return null after a display was added, in the case the binder call to get the display instance was in flight while getDisplay was called.

This cl regretfully makes getDisplay return the cached Display instance if available, or makes it trigger a binder call to get the Display if we know its id was added already. While this might cause regressions, it's necessary to ensure correctness. Anyway, the binder call shouldn't happen more than once per display id, so I don't expect the impact of this to be that high.

A new method with the old non-blocking behaviour has been added: getCachedDisplay.

Bug: 362719719
Bug: 410580872
Test: DisplayRepositoryTest
Flag: NONE - small performance bugfix
Change-Id: Iaf41e17222315359c01d8cf3590dc8e3d177d01d