Fix save mission and campaign on linux for QTFred

[JohnAFernandez]

Basically, this is an easy workaround for a specific linux issue. We could edit the qt file dialog to work in all cases, or we could just check for the correct file extension and then add it when it's not there.

Also, optionally add .patch files from git's patch functionality to git ignore for convenience.

[Goober5000]

Codex had one finding:

[P1] Adding the extension after the dialog bypasses overwrite confirmation — FredView.cpp, lines 526–527

On the affected Linux dialogs, entering example when example.fs2 already exists checks whether example exists. This change then appends .fs2, and the mission saver replaces the existing mission without asking. With backups disabled, its previous contents are lost.

Configure the dialog’s defaultSuffix before showing it, or explicitly check and confirm replacement after appending the extension.

The campaign path has the same concern, although its saver already appended .fc2 internally, so that overwrite issue predates this PR.

[JohnAFernandez]

It looks like the logic for that check exists in QFileDialog if it exists. If we're trying to avoid a deep dive into editing QFileDialog, we would probably have to ask if a user is ok with overwriting the original separately from that dialog. So we either have to ask the majority of users twice, or write some preprocessor logic to check if they are on one of the affected distros before asking outside the dialog. And I'm not sure how we would get a list of those.

The average linux user is going to be fairly skilled though, and they're not likely to run into this. We could create a separate issue to discuss and search for a fix?

[Goober5000]

You might be thinking of something else -- this particular issue is both common and not too complex. No distro checks or editing of Qt is required. The essential change is this:

if (!saveName.endsWith(".fs2", Qt::CaseInsensitive)) {
    saveName += ".fs2";
    // If this new path exists, confirm replacement before saving.
}

Codex also said this:

If the dialog already returned .fs2, its existing confirmation handles that path. If we append .fs2, we’re changing the destination, so confirmation must cover that new destination.

Also, my defaultSuffix suggestion meant configuring a QFileDialog instance through its public API, not modifying Qt itself.

I wouldn’t defer this based on Linux users’ experience. Entering a filename without its extension is ordinary usage—and precisely the workflow this PR aims to support.