builtin/clone: fix segfault when using --revision with protocol v0

Servers supporting protocol v2 do not advertise excess refs and honor `transport_ls_refs_options.ref_prefixes` when $ git clone --revision=refs/heads/main $URL contacts them, but when talking to a server that does not support protocol v2 the client segfaults. This can also be observed when v0 is enforced for example by $ git -c protocol.version=0 clone --revision=refs/heads/main $URL In the protocol v2 case the server honors `transport_ls_refs_options.ref_prefixes` and in `cmd_clone()` the linked list `refs` returned by `transport_get_remote_refs()` only contains a single item, which is the ref requested with the --revision argument. Both `remote_head` returned by `find_ref_by_name()` and `remote_head_points_at` returned by `guess_remote_head()` are NULL. The guard in `update_remote_refs()` skips a the affected code because `remote_head_points_at` is NULL. In the protocol v0 case in `cmd_clone()` the linked list `refs` returned by `transport_get_remote_refs()` contains many items, amongst others "HEAD". `remote_head` returned by `find_ref_by_name()` is not NULL and `remote_head_points_at` returned by `guess_remote_head()` is not NULL but its field `peer_ref` is NULL. Because `remote_head_points_at` is not NULL the guard in `update_remote_refs()` does not skip the affected code and `remote_head_points_at->peer_ref->name` is accessed, which causes a segfault later on. Signed-off-by: Adrian Friedli <adrian.friedli@mt.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>