Fix streamDiff tests

[my8bit]

There was a use case that where failing because it expects the old ( or - ) to come only after the new (or +). Code produces the correct diff but is structured in a way that injects the + first. In this PR instead of inserting the + first, the algorithm stores - in the stack and interest before the upcoming + this is the way it reprioritizes the - changes over + in the final diff.

Example before the change:

    + D
    + E
    - A
    - B
      C
    + F
    + C

now becomes

    - A
    - B
    + D
    + E
      C
    + F
    + C

But exploring the logic around that there are some open questions still for me that I'd like to understand. Here is some logic, that aims to prevent bugs I assume which I commented on to make a match:

      if (
        newLine.trimStart() === oldLines[i].trimStart() // &&
        // (permissiveAboutIndentation) || newLine.trim().length > 8) 
      ) {

in this case when we compare the } with } we trim the start and get the } and } but as long as permissiveAboutIndentation is false and "}".trim().length is not longer than 8 it's not matching the closing brackets correctly.

@sestinj could you please have a look at the updated logic, that fixes the test? Is it something that the test intends to cover initially? If yes, then let's think about how we can adjust this logic (permissiveAboutIndentation) || newLine.trim().length > 8) to not cause the potential regression. Because seems that it was needed to cover some edge cases. If you can give an example of that, it's also possible to cover it here in the test to avoid regression in the future.

[sestinj]

appreciate this, glad it caught a bug. Want to manually test a bit myself before merging but will try to do this tomorrow