Posible bug with GIT_DEFAULT_HASH during clone

[Matheus Tavares <matheus.bernardino@xxxxxx>]

Hi, everyone

Documentation/git.txt mentions that GIT_DEFAULT_HASH is ignored during
clone, but I think it may not be *totally* ignored, sometimes leaving
the config file on the cloned repo in an inconsistent state.

To reproduce this (tested with current `master` and `seen`):

git init test
echo F>test/F
git -C test add F
git -C test commit -m F
export GIT_DEFAULT_HASH=sha256
git clone test test-clone
git -C test-clone status

Which outputs:
fatal: repo version is 0, but v1-only extensions found:
        objectformat

>From what I could see under gdb, the steps leading to this are:

- First, this call chain gets the GIT_DEFAULT_HASH value:
  cmd_clone() > init_db() > validate_hash_algorithm().

- Then, init_db() calls create_default_files(), which calls
  initialize_repository_version() with GIT_HASH_SHA256, setting these
  configs:
  * extensions.objectFormat=sha256
  * core.repositoryFormatVersion=1

- Finally, cmd_clone() later uses the return of
  transport_get_hash_algo() to call initialize_repository_version()
  again, but with GIT_HASH_SHA1, setting:
  * core.repositoryFormatVersion=0

So we end up with the repository format version as 0 but the
objectFormat extension is present.

Thanks,
Matheus