API for home support on virtual displays.

Instead of adding yet another virtual display flag, the API is in
VirtualDisplayConfig and uses WM's DisplayWindowSettings to store the
bit whether home is supported.

The difference with the existing FLAG_SHOULD_SHOW_SYSTEM_DECORATIONS
is that it also adds navigation bar and the new API doesn't. The flag
is hidden but there are existing clients of it.

Several caveats:
 - Need to use displayUniqueId instead of displayId because we should
   tell WM about the home support before the display is actually
   created and the display listeners notified.
 - Interacting with the DisplayWindowSettings requires the WM lock,
   which must not be acquired while DisplayManagerService is holding
   its own lock because this may and will sometimes cause deadlock.
 - So extracting the displayUniqueId generation logic before the DMS
   locked region of actually creating the virtual display and passing
   it to WM to store the settings.
 - Change in the virtual display uniqueId generation: reusing ids per
   package/uid causes problems in when displays with the same name
   are created and released quickly (CTS). When there are no display
   devices, the same unique id is used, but the DisplayWindowSettings
   may not have yet received the previous onDisplayRemoved callback,
   so the setting for that uniqueId is removed. Making the uniqueIds
   truly unique fixes this and there's no realistic danger of an
   overflow.

Fix: 291749213
Fix: 297167917
Test: see CTS in topic
Test: atest VirtualDisplayAdapterTest
Test: atest DisplayWindowSettingsTests
Test: atest DisplayAreaPolicyTests
Change-Id: If72696a793a9c4d63d4f8b72de7433b0dd440909