Re: [RFC] strbuf's in builtin-apply

Following this mail will happen a new janitoring series. This is a rewrite of the former, using Junio's advice to use strbufs in convert_to_* functions. The patch hence becomes more intrusive than before (in convert.c mostly). Note that this imply that now strbuf.h is included from cache.h so all git sources see strbuf's.

The convert_to_git patches gain some marginal efficiency as the new API makes the reuse of the buffers possible when in-place editing works (e.g. the \r\n -> \n can be done in place, we save a malloc here). Else nothing should have changed significantly.

The last 2 patches are new. The first one is a simplification of the code splicing the "encoding" header in commit.c, reusing the logic already in strbuf.c for that matter, and also making the parsing code easier to read (IMHO).

The latter further simplify some code that was trying to guess if rfc2047 encoding of some header was needed. Thanks to strbuf_grow, and the fact that now at each point we can grow buffers (which was harder before), I tried to wait until we are sure if rfc2047 encoding will be needed or not to extend the buffer. I've benchmarked many tools (on real repositories, with commiters having non ascii chars in their name) using the pretty printer without noticeable changes in the numbers (and rather again, a trend to be faster, but with less than a percent gain, so I won't call it a real gain).

The series is based on next, as many patches are definitely not suitable for master :)