Add file_operator handled support for dealing with commit content

[sahansk2]

Fixes #288

Right now, these tests are pretty hacky, and GitPython keeps marking untracked files that are added to the staging area as "deleted". I'm using iter_change_type to get the changes. What are your thoughts, @benthayer ?

[sahansk2]

@benthayer Yep, I understood all of your comments! I think this is ready to be reviewed: tests are passing and the behavior is as you requested it.

[sahansk2]

@benthayer All changes have been implemented, with full support for directories (see test_operator.py). This is ready for review again.

[sahansk2]

Marking as draft, since this is currently incompatible with Windows:

https://github.com/sahansk2/git-gud/actions/runs/221208128

[sahansk2]

Some comments on the errors...

         else:
>           return self.get_commit_content(commit_hash)[filepath]
E           KeyError: 'dir\\subdir\\subdirfile.txt'

I suppose pathlib's Path automatically resolves to the default operating system's separators. We might have to use only PosixPaths or something.

         # Test unmodified
        assert "Welcome.txt" in staging_data
>       assert staging_data["Welcome.txt"] == working_data["Welcome.txt"]
E       assert 'Welcome to G...!\r\n\r\n\r\n' == 'Welcome to G...it-gud!\n\n\n'

This probably has something to do with how Git works on Windows. I recall that when installing, you have to specify a checkout option, with the default being "Check out windows endings, commit unix endings". It might have something to do with that. Python might also be converting the \r\n to \n all by itself when it reads the file, which explains why working_data doesn't have the carriage returns, while staging_area does -- which is likely if the raw data is being read from staging_area.

        for untracked_file in untracked_files:
>           assert untracked_file in working_data
E           AssertionError: assert 'dir/untracked.txt' in {'Welcome.txt': 'Welcome to Git Gud, a command line game designed to help you learn how to use the popular version con...rfile.txt': 'dir/subdir/subdirfile.txt content', 'dir\\subdir\\untracked.txt': 'dir/subdir/untracked.txt content', ...}

This probably has something to do with how the key is initialized. I think it's being directly copied over from an instance variable.

 >           assert added_file in working_data
E           AssertionError: assert 'dir/added.txt' in {'added.txt': 'added.txt content', 'dir\\added.txt': 'dir/added.txt content', 'dir\\subdir\\added.txt': 'dir/subdir/added.txt content', 'dir\\subdir\\subdirfile.txt': 'dir/subdir/subdirfile.txt content', ...}

Same deal here.

That being said, I'm closing this so that I can rebase on a branch with Windows and macOS testing via GitHub actions.