Kidney blame's behaviour and edge cases

Definition: "kidney blame" == "blame -r N:M" with M<N. Currently it is
an error (raised by svn_client_blame5()).

By and large, it should do exactly what 'blame -r M:N' does: walk the
revisions from "before-the-colon revision" to "after-the-colon revision"
and then print the contents of the "after the colon" revision, with each
line annotated by the revnum of the "rightmost" (that is: nearest to the
revnum on the right of the colon) revision within the range that added
that line. In other words, if
(iota_at_4, kappa_at_1), (iota_at_3, kappa_at_2), (iota_at_2, kappa_at_3), (iota_at_1, kappa_at_4)
are pairs of byte-for-byte-identical files, then 'blame -r 1:4 kappa'
and 'blame -r 4:1 iota' will output the same thing.

Currently, the non-kidney blame checks one revision before the start ---
that is, 'blame -r M:N' actually calls svn_ra_get_file_revs2(start=M-1,
end=N). The purpose of this is to differentiate "lines added in rN"
from "lines present since before rN". That makes 'blame -r M:N'
correspond to 'diff -r M-1:N' or 'diff -c M:N', in that it also shows
changes made _by_ rM, not only _since_ rM.

That behaviour cannot easily replicated for the -r N:M case since it's
not possible to cheaply find the "next interesting revision" after rN,
but in any case I think it shouldn't be: 'blame -r M:N' should not have
automagically decremented M --- instead, if the user had wanted to see
what lines were added in rM, as opposed to before it, the user should
have specified M-1 as the start revision. That way, 'blame -r M:N'
would be consistent with 'diff -r M:N'.

So I suggest that blame -r N:M not try to find the "next change after
rN" (that's the analogous thing to what "decrement M" is in the '-r M:N'
case). That means -r M:N and -r N:M are assymetrical, and I propose we
fix that by making -r M:N not decrement M --- which we can probably only
do in 2.0.

---
Another issue: what should 'blame -r 3:3' do?  Currently it is allowed,
and prints '-' for lines added before r3 and '3' for lines added in r3.
I am not sure whether that is intentional / by design, or just an
accident of the fact that whoever added the 'end_rev < start_rev' check
should have used the broader condition 'end_rev <= start_rev' instead.
(See r7438 <-> http://svn.apache.org/r847512).
It seems to me it should ideally print '3' for every line, and the user
should pass '-r 2:3' if he wants to distinguish "added in r3" from
"added before r3".  It would be easy to preserve the current behaviour,
though, of printing '-' rather than '2' (where '2' here is the youngest
change to that line, for lines added before r3).
---
Cheers,
Daniel