Mac kext: Profile performance impact of O(N) searches, replace with O(1) or O(log(N)) as appropriate

There are a few places where the kext performs potentially performance-draining linear searches:

• FindRootAtVnode_Locked() - linear search of roots array by vnode/vid and fsid/inode. Most calls to this via FindOrDetectRootAtVnode() from the loop(!) in VirtualizationRoot_FindForVnode() will not find a match and thus walk the entire array. (i.e. O(n*m)) The vnode cache will presumably reduce the number of calls to this, but it's still very inefficient and I wouldn't be surprised if it showed up as a hotspot in profiling.
• FindUnusedIndex_Locked() - linear search for unused item in roots array. This one is only called when discovering or registering a virtualisation root, so it runs rarely enough that we probably don't care.
• KauthHandler_HandleKernelMessageResponse() - linear search of linked list for outstanding message matching message ID received from provider. This list should normally be quite short, so hopefully not much of an issue.

We should probably profile these, particularly in situations where there are quite a few VFS4G repos (roots) on the system, and see if it's worth using hash tables or trees to index the data structures.

Start by locating FindRootAtVnode_Locked(), FindUnusedIndex_Locked(), and KauthHandler_HandleKernelMessageResponse() in the kext. Profile workloads with many VFS4G repositories, focusing on root lookups and outstanding message searches. Done means the hotspots are measured and the affected searches have an agreed indexing approach, if profiling shows it is warranted.