Fix: Replace slow custom trash implementation with native trashItemAtURL: API

[delacrixmorgan]

Problem

Discarding working directory changes in GitUp causes a noticeable lag before files are removed from the list. The moveItemAtPathToTrash: method in GCFoundation.m used a custom implementation that:

1. Searched for the Trash directory via NSSearchPathForDirectoriesInDomains
2. Manually computed destination paths with collision avoidance (looping with incrementing counters)
3. Called moveItemAtPath:toPath: for each file

This approach is slow because:

• The while loop checks for existing files in Trash one-by-one using fileExistsAtPath: — O(n) per conflict
• moveItemAtPath:toPath: across volumes (e.g., external drives) has no optimization
• The Trash path resolution is redundant work the system already handles

Solution

Replaced the 14-line custom implementation with Apple's native NSFileManager API:

- (BOOL)moveItemAtPathToTrash:(NSString*)path error:(NSError**)error {
  return [self trashItemAtURL:[NSURL fileURLWithPath:path] resultingItemURL:nil error:error];
}

trashItemAtURL:resultingItemURL:error: (available since macOS 10.8) is Apple's optimized system API that:

• Handles filename collision resolution internally and efficiently
• Works correctly across volumes (uses the volume's .Trashes folder when appropriate)
• Uses optimized filesystem operations under the hood
• Properly integrates with Finder's "Put Back" functionality

[lucasderraugh]

Was there a reason you didn't want to integrate this change, seemed decent.

[delacrixmorgan]

It broke the Undo and Redo function with my changes, let me test more.