[RFC]: strcat/strncat

[Ondřej Bílka]

Now my strlen starts to look complete so I can return back 
to strcat/strncat question.

There is dependency of strcat implementation on different strlen
implementations. I proposed in october to used a simple generic 
implementation.

My main reason is that I did not found a binary that stress strcat 
enough so using strlen/strcpy would be faster thanks to better cache 
usage.

I did profiling with results below, part strcat.
http://kam.mff.cuni.cz/~ondra/benchmark_string/profile/result.html

Important part there is 'delays between calls' graph. It shows that
calls are not clustered so it will not stay in instruction cache.

These data are caused by 58% from vim. If I do not take vim into account
then delay curve stays same, 
destinations(number of calls graphs) have same distribution as strchr,
in source sizes (needle graph) there are almost no sources bigger than 8
bytes.

Also strlen is called 650 times more and strcpy 100 times more than
strcat. 
For strcpy part there is possible optimization to split headers into
two variants where one has additional argument that it returns. This
allows us to jump to that variant.