Avoid reallocating argv array

The client argv array was previously always zfree()/zmalloc()'d whenever
its size needed to change. In practice, if it's too small, it requires a
realloc. But if it's too big, there's virtually no cost to simply
leaving it big and keeping track of its "physical size" (c->argv_size in
this patch) separately from the actual argument count (c->argc). This is
all based around the assumption that if we see a command with N
parameters once, we are likely to see a command with such a count of
parameters again.

Right now, the way that we allocate the argv array size is based on
"whatever is needed unless its less than geometric growth by the golden
ratio, then grow by the golden ratio". This enforcement of geometric
growth is to avoid growing the array piecemeal. It's generally a useful
technique, but this is probably not its most significant application, so
one might argue it should be replaced by simply growing the array to
whatever was requested (possibly +2).

Furthermore, one might argue that this incurs a leak of
sizeof(robj*)*argv_size if we see a command with many, many parameters
once and never again. I really don't think this is a practical concern,
but one could add logic to conditionally shrink the argv array again.
For example, this could work as "if the requested size is larger than
$some_minimum_length and smaller than half the size of the current argv
size, then shrink it to the requested size (+2)". This opens up the
possibility of getting stuck in shrink/grow loops in obscure corner
cases, of course. I don't think it's worth the hassle.

The reason why there's a few +2's scattered across the above is because
there are a number of situations where one might follow up a command
that acts on a top level key (eg del) with a command that adds just a
few parameters (eg. del foo; hset foo bar baz).

Performance: This change provides a small but measurable speed-up.
According to callgrind, prior to this change, Redis spent about 18% of
the time in processMultibulkBuffer in zfree/zmalloc. After this change,
the replacement code takes up less than 1% of the time (of
processMultibulkBuffer).

  src/redis-benchmark -p 6379 -P 32 -n 1000000 hset foo bar baz

appears to run a few percent (4%, measured with CPU turbo disabled)
faster on the modified Redis.

Much more savings could be achieved by avoiding (re)allocating the
actual robj's that make up the argv array. That's something to explore
later.