[PATCH] Improve reporting WC is locked/busy ('run cleanup')

The attached patch makes some improvements to how we report that the WC
is locked or busy (the 'run cleanup' messages). I need a sanity check
to make sure I've understood the relationship between how we want to
handle 'the work queue is busy' and 'there is a write lock on a WC
directory'.

When the WC is locked we may (depending on the timing) see:

  $ svn up -q & svn up -q
  svn: E155004: Working copy '/home/...' locked.
  svn: E155004: '/home/...' is already locked.
  svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)

(or, depending on the timing, there may be two 'database is locked'
lines instead of the 'is already locked' line), or

  $ svn up & svn commit
  svn: E155004: Commit failed (details follow):
  svn: E155004: Working copy '/home/...' locked.
  svn: E155004: '/home/...' is already locked.
  svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for
details)

When the work queue is not empty, we see:

  $ svn status
  svn: E155037: Previous operation has not finished; run 'cleanup' if it
was interrupted

My recommendations, mainly for the WQ-not-empty case:

1. The 'E155037' message shown above comes from libsvn_wc. But the
part about running 'cleanup' should be added by 'svn', since in other
clients it may have a different name or may not be applicable at all,
especially if the client can find out that in fact the other operation
is still running. So libsvn_wc would say just:

  "A previous operation on the working copy has not finished"

and 'svn' would wrap that in:

  "Run 'svn cleanup' if the previous operation was interrupted"

See also point (2).

2. Consider wrapping this SVN_ERR_WC_CLEANUP_REQUIRED (E155037) error
in a SVN_ERR_WC_LOCKED (E155004) error to preserve API compatibility
w.r.t. this kind of situation. Inside libsvn_wc, of course the
condition being reported here is not the same as a 'lock', but to an
outside caller the net effect is basically that it's a lock.

If we don't wrap this in SVN_ERR_WC_LOCKED, then in order to support
(1), 'svn' should learn to recognize the new error code as well, at the
point where it determines whether to suggest the user should run
'cleanup'.

3. The error code SVN_ERR_WC_CLEANUP_REQUIRED is misnamed, since
libsvn_wc does not know whether cleanup is required. Rename it to
SVN_ERR_WC_BUSY or SVN_ERR_WC_WORK_QUEUE_NOT_EMPTY.

4. libsvn_wc should include the WC root in the error message:

  "A previous operation on the working copy at '<wcroot_abspath>' has
not finished"

5. 'svn' should print its message about running 'cleanup' via the
standard error message mechanism instead of using cmdline_fputs(), so
that the message appears in the standard (new) format with the
'Ennnnnn:' prefix. This suggestion is independent of the others so I'll
commit it separately, but it's included in this patch for you to see.

With this patch, typical results are:

  $ svn up -q & svn up -q
  svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help
cleanup' for details)
  svn: E155004: Working copy '/home/...' locked.
  svn: E155004: '/home/...' is already locked.

  $ svn up -q & svn commit
  svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help
cleanup' for details)
  svn: E155004: Commit failed (details follow):
  svn: E155004: Working copy '/home/...' locked.
  svn: E155004: '/home/...' is already locked.

and for the more interesting, WQ-not-empty, case:

  $ svn status
  svn: E155037: Run 'svn cleanup' to remove locks (type 'svn help
cleanup' for details)
  svn: E155037: A previous operation on the working copy at '/home/...'
has not finished

I would propose all of this for 1.7.0 back-port.

Concerns?

- Julian