feat: handle file move then edit scenario

[mshanemc]

What does this PR do?

when a file is moved, but then also modified before doing preview|deploy|retrieve

before:

the hashes didn't match, so both the "add" and the "delete" were shown/used

after

the "add" is kept (ex: it would show up a something to deploy) but the "delete" is committed/cleared (it would not show up as something that needs deleting)

other

• move to oclifv4 (STL only uses the Performance hook, which is now a standalone export)

What issues does this PR fix or reference?

@W-15840593@
forcedotcom/cli#2880

[mshanemc]

with the more complex result object, this made more sense to handle outside the ShadowRepo class

[iowillhoit]

QA NOTES

• 🟢 Move files are not detected when SF_BETA_TRACK_FILE_MOVES is not set
• 🟢 Single moved class are detected when SF_BETA_TRACK_FILE_MOVES=true
• 🟢 Full object dir is detected
• 🟢 Moving a decomposed md-child to a different parent is not detected as a move
  • 🟢 Moving it back clears tracking
• 🟢 Moving and then editing a file commits the delete and shows the add
• 🟢 Moved images are detected
• 🟢 Moving an image and then editing it commits the delete and shows the add
• 🟢 Moving a file out of the project directory shows as a delete
• 🟢 Moving a full object dir AND editing one internal file:
  • 🟢 Commits the files that were just moved
  • 🟢 Commits the delete and shows the add of the file edited
• 🟢 Editing a file (no move) shows as add
• 🟢 Deleting a file (no move) shows as delete
• 🟢 Copying a file to a new location shows as add as expected
• 🟢 Nuts passing

[iowillhoit]

Looks good. Will fix conflicts