ExternalData: Avoid replacing a concurrently-created object

If more than one content link references the same object, the build system may launch multiple download processes for the same object concurrently. Use whichever one finishes first, and discard the others.

Without this, we replace the objects and use the last finisher instead of the first. This is okay on non-Windows platforms where rename(2) gives reliable atomic replacement. However, on Windows platforms and NTFS this is less reliable. I've observed MoveFileEx somehow cause another process to get ERROR_SHARING_VIOLATION when attempting to read the destination file. We may be able to improve the file(RENAME) implementation on modern Windows 10 versions, but for ExternalData's use case it is simpler to just not replace existing objects.