More accurate modified line counts

If Resyntax suggests replacing this code:

(define (foo)
  (define (bar)
    42)
  ... hundreds of lines of code ...)  

With this code:

(define (foo)
  ... hundreds of lines of code ...)

(define (bar)
    42)

Then something odd happens with modified line counting. GitHub will say that the diff removes two lines (the original nested bar definition) and adds three lines (the new, module-level bar definition). Resyntax, however, will say that hundreds of lines of code were modified because everything in foo after the original nested bar definition has to be included in the line replacement. Using ~focus-replacement-on doesn't help either, because we're not changing an expression within a nested context: we're moving it to a different context entirely. This causes --max-modified-lines to appear to disagree with the GitHub pull request size.

A possible fix might be to inspect the line-replacement generated by a suggestion and do something a bit smarter to determine whether any lines were simply moved instead of actually modified.

Start by tracing how a suggestion's line-replacement is generated and how modified lines are counted; reproduce the nested-to-module-level Scheme example from the issue. Determine how moved lines should be distinguished from changed lines, then verify that the resulting count matches the intended pull-request size and --max-modified-lines behavior.