[RemoteFeatureFlagController] Unclear behaviour on threshold ordering.

When creating threshold variations, we did not know that variations were to be ordered in ascending order.

For example we had these variations, and didn't realise our "Control" variant was always selected.

See examples and loom recordings

Our variations:
```jsonc
"tokenDetailsV2AbTest": [
// "control" variant is always selected, as we never order variants by scope.
{
"name": "Control is ON",
"scope": { "type": "threshold", "value": 1 },
"value": { "minimumVersion": "7.67.0", "variant": "control" }
},
{
"name": "Control is OFF",
"scope": { "type": "threshold", "value": 0.1 },
"value": { "minimumVersion": "7.67.0", "variant": "treatment" }
}
]
```

Some loom walkthroughs:
- https://www.loom.com/share/b6c44e72b22f4a298ab2c3bb3ff27905
- https://www.loom.com/share/5daecf94763a4536b13db393310e0ed2

[Example failing test case added to this draft PR](https://github.com/MetaMask/core/pull/8120)

Is this the intenional behaviour (that threshold scopes must be ordered by ascending value).
- If yes, we can take the above draft and solidify some unit tests and documentation around this behaviour.
- PR: https://github.com/MetaMask/core/pull/8129
- If no, we can add a small fix to ensure we sort threshold scopes before processing and picking threshold groups.
- PR: https://github.com/MetaMask/core/pull/8128

Start with the example failing test in draft PR 8120 and inspect how RemoteFeatureFlagController processes threshold variations. Review PRs 8128 and 8129 to determine whether the intended outcome is sorting thresholds or documenting and testing the required ordering; done means the selected behavior is covered by unit tests.

Written by the indexing model from the issue text.