follow the "proper secure idiom" described in the CAVEATS section of printf(3). reminded by tb@ and millert@

Found by llvm's scan-build (dead store). OK stsp

ok thomas_adam millert

ok naddy

Both GOT_FETCH_PKTMAX and GOT_SEND_PKTMAX had the same value. Declare this value as GOT_PKT_MAX in got_lib_pkt.h instead.

Move functions and data structures which implement Git protocol features required for fetching and sending pack files to new files lib/gitproto.c and lib/got_lib_gitproto.h. This code was duplicated in got-fetch-pack and got-send-pack. No functional change.

The Git protocol uses a simple packet framing format. The got-fetch-pack and got-send-pack programs contained identical copies of functions to support this format. Move related functions to new file lib/pkt.c and link both programs against this common implementation. No functional change.

The git protocol spec says the client MUST NOT send a pack file if the only command used is 'delete'. Fixes 'got send -d' against Github's server which closed the session upon receiving the empty pack file we sent. This problem wasn't caught by regression tests since git-daemon does accept an empty pack file. Problem reported by jrick.

This workaround was inherited from git9, which claims that Github did not send capabilities. Protocol traces show that Github's server does in fact advertise its capabilities. Git protocol capabilities are hidden behind a NUL byte in the middle of the first refline sent by the server. This makes them easy to miss when treating a refline as a C string. I guess this is why Ori concluded that Github didn't send any capabilities. Or perhaps Github has been fixed since.