Checklist

• I've included the output of alr version.
• I've included complete steps to reproduce my issue.

Describe the bug
On Debian based systems, you can have different OS package names that provide a given external library. This depends on the OS version but also on some package alternatives. Examples:

• libcurl4-openssl-dev vs libcurl4-gnutls-dev: both are valid for the libcurl external library,
• libmariadb-dev for recent Debian version and libmariadbclient-dev for older ones

The following pull request alire-project/alire-index#1085 suggest that we can express such alternatives by writting:

"debian|ubuntu" = ["libmariadb-dev",      # newer Debian versions
                   "libmariadbclient-dev" # older Debian versions
                   ]

However, only the first alternative is considered: if the second alternative is installed on the system, it is not checked and alr asks for the installation of the first alternative.

Following the libmariadb dependency fix, I would like to fix the libcurl dependency as follows:

"debian|ubuntu" = ["libcurl4-openssl-dev","libcurl4-gnutls-dev"]

To Reproduce
Steps to reproduce the behavior:

1. Setup a libcurl dependency with:

    "debian|ubuntu" = ["libcurl4-openssl-dev","libcurl4-gnutls-dev"]
   

2. Install libcurl4-gnutls-dev on Linux
3. Run alr with libcurl => it tries to install libcurl4-openssl-dev
4. Change the libcurl dependency to:

    "debian|ubuntu" = ["libcurl4-gnutls-dev","libcurl4-openssl-dev"]
   

5. Run alr with libcurl => dependency is met
6. Uninstall libcurl4-gnutls-dev and replace it by libcurl4-openssl-dev
7. Run alr with libcurl => it tries to install libcurl4-gnutls-dev

Expected Behavior
Dependencies are met when one of the two system package is installed.

alr version
APPLICATION
alr version: 2.1.0-dev+c864eeff
libalire version: 2.1.0-dev+c864eeff
compilation date: 2024-06-30 10:02:23
compiled with version: 12.1.0