Fixed buffer problems in doShellEscape

When the output from a command is empty, nothing stops doShellEscape from
chopping newlines past the beginning of the buffer.  This problem was first
identified by Dmitry V. Levin in July 2009.

Also, there is an off-by-one error in replacing trailing '\n' with '\0'.
This problem, however, escaped the attention of Dmitry V. Levin in July 2009.
Optimize expandMacro function

This change brings the following optimizations:
- In the beginning of the routine, the input string needs to be copied
  only in non-terminated case.
- When mb->buf is NULL, expensive xcalloc call is replaced with xmalloc.
  It suffices to ensure that mb->buf is (initially) null-terminated at
  mb->tpos, and that mbAppend* routines follow this rule.
- The inner per-character loop is replaced with call to strchr(s, '%').
  Also note that the "trailing %" case is no longer handled by this part
  of the code (this is now the case of no valid macro name).
- New routine mbAppendStrn now complements mbAppendStr.  Also, mbGrow
  routine was factored to improve possibilities for inlining.

Callgrind annotations for 'rpmspec -P selinux-policy.spec', previous commit:
160,979,831  PROGRAM TOTALS
58,348,925  rpmio/argv.c:argvCount
14,378,832  build/parseSpec.c:readLine
10,710,181  glibc-2.16-75f0d304/string/../sysdeps/x86_64/memset.S:__GI_memset
 5,445,134  rpmio/macro.c:mbAppend
 5,147,651  glibc-2.16-75f0d304/malloc/malloc.c:_int_malloc
 3,490,055  rpm-4.10.2/lib/header.c:copyData
...

Callgrind annotations for 'rpmspec -P selinux-policy.spec', this commit:
140,610,489  PROGRAM TOTALS
58,348,925  rpmio/argv.c:argvCount
14,378,832  build/parseSpec.c:readLine
 3,893,942  glibc-2.16-75f0d304/malloc/malloc.c:_int_malloc
 3,490,055  rpm-4.10.2/lib/header.c:copyData
...

Update:
- Explicitly assert that the buffer is null-terminated before return.
- Made mbAppend* routines inline.
Optimize readLine routine

This change introduces the following optimizations:
- Line chunking used to be done with per-character loop; it now uses
  strchr(line, '\n') call.
- Likewise, the "balancing check" has been enhanced with strpbrk(3).

Callgrind annotations for 'rpmspec -P glibc.spec', previous commit:
94,796,525  PROGRAM TOTALS
33,242,383  rpmio/argv.c:argvCount
 9,886,925  build/parseSpec.c:readLine
 3,964,158  glibc-2.16-75f0d304/malloc/malloc.c:_int_malloc
...

Callgrind annotations for 'rpmspec -P glibc.spec', this commit:
88,013,018  PROGRAM TOTALS
33,242,383  rpmio/argv.c:argvCount
 3,964,158  glibc-2.16-75f0d304/malloc/malloc.c:_int_malloc
...

Update: on the second thought, it occurred to me that two more
optimizations related to the "balancing check" can be implemented:
- Note that the check actually does two different things: it tracks
  line concatenation with trailing backslash; and it further checks
  for balanced brackets and parens, but only within a macro substitution.
  Unless a macro has been started, the check for brackets/parens can be
  skipped.  Likewise, unless a trailing backslash has been seen, there
  is no need to search for a newline.  Thus, strpbrk() can be first
  called with a reduced set of characters: only "\\" and "%" have to be
  tracked down.  When a trailing backslash is found, or when a macro
  substitution is started which needs a closing bracket/paren, the set
  of character is changed to a full set of "\\\n%{}()".
- The balancing check can also be used to find out whether the
  rpmExpandMacros() call is needed at all. Note that, on average, only
  about 30% of specfile lines have "%" character in them (among the
  remaining 70% are empty lines with trailing "\n", which nontheless
  still have to be processed).  Thus most of the rpmExpandMacros() calls
  and the associated buffer allocation/copying can be skipped altogether.

Callgrind annotations for 'rpmspec -P glibc.spec', updated commit:
80,831,100  PROGRAM TOTALS
33,244,684  rpmio/argv.c:argvCount
 3,244,420  glibc-2.16-75f0d304/string/../sysdeps/x86_64/strcmp.S:__GI_strncmp
...

Update2: it is not clear whether the backslash in "\%{foo}" should
somehow "escape" the balancing check, as it does now.  Anyway, this case
is still subject for macro expansion.