[BUG] basic auth not send on empty password in default configuration

Hit this issue playing with a custom credential helper:

- if the server requires authentication for an operation (returns 401 on
   an un-authenticated request)
- and the credential helper sets an empty username and a non-empty
   password
- the second request git sends is still un-authenticated instead of
   having basic auth set
- git then fails with an "authentication failed" error

If proactiveAuth=basic is enabled, git doesn't mind the empty username and sends the request with basic auth set.

This was directly observed on git 2.47 and 2.55, with curl 8.5.0.

The issue seems to come from init_curl_http_auth: if the username is unset *or empty*, it exits immediately unless proactive auth is enabled, which matches the symptoms. From this it looks like an other workaround would be for the credential helper to precompute the `credential` value and return that instead of username/password, as that is guaranteed to be non-empty.

Either way the current behaviour is somewhat surprising as (AFAIK) nothing in basic auth requires non-empty usernames (or even passwords), and importantly git doesn't report anything odd except the connection failing, the lack of auth on the second attempt is only visible when enabling GIT_CURL_VERBOSE and comparing a successful auth with an unsuccessful one (or on the server side, but there if the server is bespoke one can easily chase ghosts assuming the error is obviously somewhere in the bespoke code because select isn't broken).