Summary of the pull request

Loading and displaying Hyper-V VMs data on Landing and SetupTarget pages has a visible delay that is caused by several factors:

1. First time interacting with Hyper-V VMs loads PowerShell runtime. This can cause significant delay, depending on the user's configuration. On my machine automatic loading of IxpTools add ~8 seconds.
2. Getting data from DevHome Hyper-V extension can be expensive due to OOP calls.
3. We fetch Compute System data sequentially on UI thread.

This PR:
Improves 1. by removing explicit "Is Hyper-V module loaded" checks that we don't need. To make more improvements in that area we will likely need to move away from PowerShell and use WMI.
Removes OOP calls from UI thread by fetching and caching Compute Systems data in parallel on thread pool before making model initialization call on UI thread.

Video before the change:
https://github.com/microsoft/devhome/assets/51001703/51fe0672-4b36-4674-82e9-2d47a4df2604

Video after the change:
https://github.com/microsoft/devhome/assets/51001703/b77b4602-6597-46aa-9c50-1441bad8914a

References and relevant issues

Enumerating the hyper-V VMs takes longer than the experience in Hyper-V Manager

Detailed description of the pull request / Additional comments

Added ComputeSystemPropertyCache and ComputeSystemCache classes for caching VMs data via lazy initialization. Once we replace usage of ComputeSystem class with ComputeSystemCache we can merge those classes.

PR checklist

• Closes Enumerating the hyper-V VMs takes longer than the experience in Hyper-V Manager #2737
• Tests added/passed
• Documentation updated