Revert to previous order of precedence for X509 certificate variables: X509_USER_KEY/X509_USER_CERT first, then X509_USER_PROXY

In commit b68da6ee (version 2.7.0), the order of precedence of X509 certificate environment variables changed from first X509_USER_KEY/X509_USER_CERT, then X509_USER_PROXY; to X509_USER_PROXY, then X509_USER_KEY/X509_USER_CERT.

The reversal of the order of precedence broke authentication with robot certificates inside gsissh-initiated shell sessions. When the parent shell session was started with gsissh, by default gsissh delegates credentials, and always overwrites the file pointed to by X509_USER_PROXY, and deletes it upon logout. For this reason, it is necessary for projects that use robot certificates to use X509_USER_KEY/X509_USER_CERT, not X509_USER_PROXY.

This broke gwcelery's authentication for GraceDB in a subtle way. The continuous deployment pipeline uses gsissh to log in and submit condor jobs (because the clusters do not support vanilla ssh with kerberos robot keytabs). On the other hand, interactive logins by maintainers are generally initiated by vanilla ssh. As a result, whenever gwcelery was launched by the continuous deployment pipeline, GraceDB requests made using ligo-gracedb would fail with certificate errors. When launched via an interactive terminal, on the other hand, the GraceDB requests would work fine. See https://sentry.io/organizations/ligo-caltech/issues/2032438270/.

Please revert to the original order of precedence for X509 certificate environment variables: first X509_USER_KEY/X509_USER_CERT, then X509_USER_PROXY.