Select range for allowed vulnerabilities using dropdown

What does this MR do and why?

Customers want to be able to have better control over the number of vulnerabilities that an approver gets notified for. This MR modifies the previous static text "more than" into a more general-purpose dropdown, which can be later used also for #397086 (closed).

• frontend modify general text to turn the more than text into a dropdown
  • Three options: More than, Less than, Any number
    • Defaults to Any number
    • updates TBD yaml value
  • Current number input conditionally shows (this feature already exists)
    • hidden by default
    • shows for more and less
• frontend ensure the dropdwons are set to the correct values when the values are changed in yaml mode
• frontend ensure rule mode is disabled if incorrect values are added in yaml mode Extracted into a separate MR !118919 (merged)
• frontend ensure the dropdowns are set to the correct values for pre-existing policies

Note: I changed Any number from the implementation plan to Any after seeing that in the mockups. "Any number vulnerabilities" doesn't sound right, and "Any number of" seems a bit too long.

---

Screenshots or screen recordings

number_range_operator_2

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Ensure the GitLab Ultimate license is enabled
2. Navigate to a project/group => Security & Compliance => Policies => New policy => Scan result policy
3. Verify the range is set to Any number by default
4. Verify the number input is hidden
5. Change the range to any other range
6. Verify the number input is shown
7. Navigate to yaml mode, make changes to the range/number to a value that does exist, navigate to rule mode and ensure the dropdowns have been updated
8. Create the policy, edit it, verify the dropdowns assigned the appropriate values

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #396992 (closed)