run: "fix" redis boot.

I have finally found what was preventing redis from booting reliably. Two main
comments about it:

1) I have *absolutely no idea* why it was working so well before. The fpu thing
was really a red herring, nothing to do with it.

2) I believe this is technically a redis bug. However, I kind of agree with
Linus in the now famous memcpy discussion he had: just because something is (or
fail to be) in a written specification, doesn't mean we should go assigning
blame around. In the end, what matters is what works vs what doesn't

The problem is simple: redis assumes the the strings in the argv array are
contiguous in memory. They do that in such a conscious and well though manner,
that led me to believe that maybe this is specified somewhere. I didn't find
anything saying that this is a requirement. Still, redis does it.

Because they assume contiguous storage, they memset the whole region between
start and end with 0. Our strings start contiguous, because we get them from
the command line, but in the last stage of composing the array we copy them
over. If redis is ran with a single parameter, this is not a problem. But we
specify a configuration file. Also, if the memory allocator happens to make the
strings contiguous, there won't be a problem. If they are close enough, there
will be a problem but maybe we won't notice it (the likely scenario so far)

As I have said, I really have no idea why at some point in time (around the fpu
commits) that becomes more likely. Maybe this is due to Pawel's allocator
changes: they are also nearby the fpu commits and could have tricked me.

All in all, but in redis or not, I will advocate for us fixing this in OSv.
Maybe there are other people making such assumptions out there? The proposed
fix is easy: in the last step before calling main, copy all strings to a
contiguous buffer.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Avi Kivity <avi@cloudius-systems.com>