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

[Xavier Morel <xmo@odoo.com>]

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).