Split and/or provide crypto variants

### Comment:

The library supports a bunch of crypto backends. When a backend is enabled, a corresponding `libxmlsec1-{backend}` library is built. Additionally, the main library dynamically loads a backend specified as default (openssl is the default default).

What I'm thinking of is:

1. Splitting the package so that individual crypto backends can be installed independently, i.e. having `libxmlsec1-openssl`, `libxmlsec1-gnutls`, etc.
2. Having variants of the main package that are compiled with different values of the default backend.

Alternatively, if that seems an overkill (I suppose we don't have any packages linking to specific backends), we could just build with one backend and introduce variants for that.

Start by inspecting the feedstock's existing package configuration and how enabled crypto backends produce their libraries. Determine whether independent backend packages, default-backend variants, or a single-backend build best fits the current packaging setup; done means the chosen package layout and default-backend behavior are clearly defined.

Written by the indexing model from the issue text.