Stage exports and swap on success instead of rmtree up front

[gsokoll]

Part of #24. Reimplemented (not copied) from ipfedor/codescribe commits bc6ec89 and 1141d7d.

Behaviour

Export To Files previously ran shutil.rmtree on the target folder before writing anything. A locked target folder (open Explorer window, IDE, git client, antivirus) aborted the export at the start, and a mid-export crash left the on-disk copy destroyed with no replacement.

The export now writes into <target>.codescribe_staging and the target is only touched after the export completes, in finalize_export_folder:

1. Swap path (normal case): rename the existing target to <target>.codescribe_backup, rename staging to the target, delete the backup. A failure deleting the backup only prints a warning; the export still succeeds.
2. Sync fallback (target locked, rename raises OSError/IOError): copy the staged files into the target file by file with os.walk, creating missing directories and overwriting existing files. Files that disappeared from staging are not deleted. The staging folder is then removed and the sync path is reported in the message view.
3. If the sync also fails: ExportFolderLockedError is raised and the error dialog names the target, says it is likely locked by another program, gives the staging folder path where the completed export is preserved, and includes the original error. Nothing is lost.

A stale staging folder from a previous failed run is removed at the start of the next export.

Live validation required before merge

• Normal export: result is SHA256-identical to a pre-change export, except intended diffs.
• Export with the target folder open in Explorer and with a file in it locked: confirm the sync fallback runs, or the dialog reports the staging folder path.
• After a successful export: no .codescribe_staging or .codescribe_backup folders left behind.

Stacked on #25; retargets to main automatically when that merges.

[gsokoll]

Live validation on CODESYS V3.5 SP11, automated via --runscript.

All scenarios passed

• Parity: staging export vs the pre-staging branch export of the identical project state, 9 files, SHA256-identical except MyFB.MyProperty.xml, where the Get and Set accessor blocks swapped order inside the recursive native export. Same-content reordering also occurs between two consecutive exports on the old code path, so it is CODESYS export nondeterminism, not a staging regression.
• Rename blocked, writes allowed (process CWD held inside the target, rename pre-verified blocked): export completed via the file-sync fallback, all files present.
• Full lock (exclusive handle on a file inside the target): ExportFolderLockedError raised with the intended message naming the target, the likely lockers and the staging path; error dialog shown; staging folder preserved with the complete 9-file export.
• No .codescribe_staging or .codescribe_backup leftovers after successful exports.