Posible bug with GIT_DEFAULT_HASH during clone

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