fix(framework-core): given files old content and new content, compute the valid hunks

[TomKristie]

Given a set of files with old content and new content, and the set of valid hunks from the remote PR, generate the hunk for each file given from the user and filter out invalid hunks and invalid files.

I created sub directories to try to add some logical grouping to the user-input to hunk/patch handling logic. This way I can distinguish between handling the user's input, and handling GitHub PR data.
It is likely that I will need to do a follow-up pr to move the github and regex logic into a submodule.

Overview of the important methods:
the src/index.ts will invoke the comment method in src/github-handler/comment-handler/index.ts.
comment gets the github pull request scopes by getPullRequestScope, and parses the user's raw changes to patches by getSuggestionPatches, and creates a pr with those patches (TODO).

This PR focuses on getSuggestionPatches:

1. get the hunks and filter invalid hunks by getValidSuggestionHunks. The two main submethods to filter invalid hunks are filterOutOfScopeFiles and filterOutOfScopeHunks
2. get the patches - TODO

Towards #59

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (comment-pr@29f5136). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             comment-pr      #86   +/-   ##
=============================================
  Coverage              ?   87.88%           
=============================================
  Files                 ?       20           
  Lines                 ?     1874           
  Branches              ?      126           
=============================================
  Hits                  ?     1647           
  Misses                ?      226           
  Partials              ?        1           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 29f5136...0111d88. Read the comment docs.

[chingor13]

You might want to include the new content here. It would simplify the algorithm:

GitHub patch -> Hunk[] -> filter based on valid ranges/file size -> convert hunk to comments -> create PR review w/ comments

You could skip having to go back and look up the content.
Maybe this is deferred to a later PR.

[TomKristie]

I use this object when I am getting the hunks. The hunk output from the diff library doesn't produce raw text. It produces a patch text with "+" and "-" prefixing certain lines and also the comment "no new line and end of file" if there is no newline and the end of the file. Therefore I'd need to alter the patch text at this step. So either way I'd need to do a raw text lookup to avoid finicky string manipulation. Therefore I have 2 choices: get and store raw text before I filter the hunks or after. If I do it after the filtration, I save on memory, which could be valuable if some strings are particularly large.

[chingor13]

Could RawContent also track its fileName? It simplifies this method conceptually that we're converting from one RawContent change to a list of Hunks

[TomKristie]

the user's input is Map<file name, RawContent> and we'd also like to keep it as a map so that we can look up the ranges of what text to apply afterwards (since the diff library text output is in patch format and modifies the original text). Therefore I could map each raw content to a RawContent + file name object. Yup it's doable, but is that object store format a better decision?

[chingor13]

If both of these are already sorted, we should be able to do this in O(n + m) time rather than O(n log m) or O(m log n).

Depending on the expected sizes of the inputs, we might want to switch.

This is non-blocking for this PR.

[TomKristie]

This would be really interesting to tackle as there'd probably need to be a lot of testing to see what the average case is for users.
#87