_ReorderProfilesToMatchUserSettingsOrder could almost certainly not be O(N^2)

[zadjii-msft]

Follow up to #2603

In #2515, we added a function that reorders profiles to match the order in the user's profiles.json. Unfortunately, it runs in O(N^2), and it almost certainly can not. While we don't believe that the number of profiles is ever high enough that this n^2 loop is ever limiting, it could always be better.

This issue represents re-writing that method to be better.

[DHowett-MSFT]

Pulling this one out of Backlog and into v1.0 -- people will have pathological case performance if they have a bunch of profiles :/

[ZhaoMJ]

So I tried to optimize it to O(n) but the effect is minimal since even though it's O(n^2), the constant of swap sort is small and _ReorderProfilesToMatchUserSettingsOrder only costs <2% CPU usage on startup anyway. The actual bottleneck is _FindMatchingProfile, which takes >60% CPU usage and causes _LayerOrCreateProfile to be O(n^2) with a very large constant from ShouldBeLayered.
As per 8/2 Rule, I think _ReorderProfilesToMatchUserSettingsOrder is not worth any optimization, but if you still want an optimization, I'm of course willing to open a PR.
If we really want to optimize the loading of profiles, we have to change _FindMatchingProfile from iterating _profiles every time to an O(1) finding algorithm, probably using std::map as an indexer.

FYI, I tried thousands of hidden profiles and it would take ~10s to start up. Anyway, I think the time of loading is acceptable now since no one actually wants such a crazy number of profiles.

[zadjii-msft]

Oh look, that function doesn't exist anymore. Easy enough!