Tighten up the restrictions on text delta producers so that it is actually possible to streamily generate XML deltas.  The producer will decide whether text deltas come inline or at the end (the consumer can't possibly make that decision without buffering all the text deltas); however, the consumer can now intuit whether a text delta will be coming at the end by the lack of a `close_file' call before the next directory operation.
Tighten up the restrictions on text delta producers so that it is
actually possible to streamily generate XML deltas.  The producer will
decide whether text deltas come inline or at the end (the consumer
can't possibly make that decision without buffering all the text
deltas); however, the consumer can now intuit whether a text delta
will be coming at the end by the lack of a `close_file' call before
the next directory operation.

I feel like our edit_fns interface now has "too much rope."
dir_batons are now redundant (there is only one allowable value for
the dir_baton argument for any call which takes one), and there is no
explicit call made when a text delta is being deferred to the end of
the call sequence.  In general, the tree structure of an editing
operation is enforced through documentation rather than through the
interface, and it doesn't have to be that way.  However, I don't feel
comfortable unilaterally instituting a major design change at the
moment, so for the moment I am just documenting the restrictions on
the call sequence.


git-svn-id: f8a4e5e023278da1e04e203c7fe051e3c4285d88@837414 13f79535-47bb-0310-9956-ffa450edef68

wbond/subversion,YueLinHo/Subversion,YueLinHo/Subversion,wbond/subversion,wbond/subversion,wbond/subversion,wbond/subversion,YueLinHo/Subversion,YueLinHo/Subversion,wbond/subversion,YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion,wbond/subversion