[PATCH 0/7] migrate api-strbuf.txt into strbuf.h

[Jeff King <peff@peff.net>]

This is a re-roll of this series:

  http://thread.gmane.org/gmane.comp.version-control.git/260922/focus=261374

from early December to move the strbuf documentation into the header
file. I've incorporated all of the minor formatting feedback and
suggestions from Jonathan and Stefan in response to that series.

Patch 2 is new from Stefan, and just fixes the comment blocks that
already existed in strbuf.h to be consistent.

Patches 3-5 are the same as the old 2-4 (modulo a header I missed in the
original of 5).

Both Junio and Jonathan noted that tighter grouping of related functions
can be more readable in some places. Patches 6 and 7 adjust those two
spots. This moves us farther from a single comment describing each
function, which may make extracting the documentation later harder. But
I think it makes reading the in-header documentation much more pleasant.

  [1/7]: strbuf.h: integrate api-strbuf.txt documentation
  [2/7]: strbuf.h: unify documentation comments beginnings
  [3/7]: strbuf.h: drop asciidoc list formatting from API docs
  [4/7]: strbuf.h: format asciidoc code blocks as 4-space indent
  [5/7]: strbuf.h: reorganize api function grouping headers
  [6/7]: strbuf.h: drop boilerplate descriptions of strbuf_split_*
  [7/7]: strbuf.h: group documentation for trim functions

The two things I _didn't_ do are:

  1. Read through for possible places to use `backticks` or other
     punctuation to make the source more readable. I think this is a
     good goal, but it's largely orthogonal, so we can build it on top
     just as easily (and also, it's tedious; I'm happy to work towards
     that goal slowly as I touch or read specific pieces of
     documentation).

  2. We do not consistently use parameter names in declarations. They
     have no meaning to the compiler, of course, but they are a good way
     of making the documentation more readable, since it gives us a
     concrete name to refer to (and also some declarations are simply
     confusing, such as when there are two ints next to each other;
     which is which?).  This is in the same boat as (1). I think it's a
     good direction, but I did not make a pass.  Patches welcome. :)

And of course the elephant in the room is the other dozen or more
api-*.txt files. I'd propose to do this strbuf.h series (and possible
follow-ons mentioned above) and stop there for a bit. That will let us
form a more coherent opinion on whether we like this system in practice,
how it ages as functions are changed and added, etc. That might affect
how or if we end up converting other files.

It does leave us in an inconsistent state (some documentation is in
Documentation/technical, and some is in the headers), but I think that
is largely where we're at today. IMHO this is a strict improvement
because at least the logical chunk of "strbuf" is now in a single place.

-Peff