Reorders two Person Authentication Scripts with the same security level

## Describe the issue
If we have two Person Authentication Scripts with "the same" security level then the oxAuth's SessionIdService class re-order passed GET param `acr_values` with the `/oxauth/authorize.htm` endpoint.

If SP doesn't provide specific `acr_values` then Gluu picked the `Default requested ACR Values' from the `Advanced Settings` tab in OIDC Client. This order was following user preferred ordering (insertion order) and maintained the exact ordering when the code determined which ACR to pick.

I came across the code changes (~2yrs ago), that would unintentionally re-order passed `acr_values` and broke the user-preferred ordering in Default requested ACR values. This creates two different experiences between the below Gluu versions:

[Gluu_v4.1.1] https://github.com/GluuFederation/oxAuth/blob/version_4.1.1/Server/src/main/java/org/gluu/oxauth/service/SessionIdService.java#L897-L906
[Gluu_v4.3.1] https://github.com/GluuFederation/oxAuth/blob/version_4.3.1/Server/src/main/java/org/gluu/oxauth/service/SessionIdService.java#L902-L917

EntryPoint in AuthorizeAction.java > checkPermissionGranted() - https://github.com/GluuFederation/oxAuth/blob/version_4.3.1/Server/src/main/java/org/gluu/oxauth/authorize/ws/rs/AuthorizeAction.java#L298

## Steps To Reproduce
- Setup two `Person Authentication Scripts` with the same security level. Named them - "Script_A and Script_B".
- Add this to any OIDC Client's Default requests ACR values in reverse order as if you wanted to authenticate using "Script_B", so the order would look like "Script_B and then Script_A".
- https:///oxauth/authorize.htm?acr_values=Script_B+Script_A&response_type=code&redirect_uri=&state=&nonce=&client_id=
- You would be taken to `Script_A` instead of 'Script_B` (because of `HashSet` usage).

## Expected behavior
`acr_value=Script_B+Script_A` with the same security level, consider user preferred ordering which is `Script_B`.

## Actual behavior
`acr_value=Script_B+Script_A` with the same security level, not consider user-preferred ordering and pick `Script_A`.

## Desktop (please complete the following information):
- Gluu Version 4.3.1, latest version
- Browser: Any modern browsers

Start with the linked SessionIdService sections in the Gluu 4.3.1 source, then follow the checkPermissionGranted() entry point in AuthorizeAction.java. Reproduce the case with Script_B and Script_A at the same security level and confirm that the requested order is preserved, with Script_B selected first.

Written by the indexing model from the issue text.