[RFC] git worktree: use filesystem cloning where supported

Hi,

I'd like to suggest a change to how git worktree creates files.

# Problem
git worktree add creates a new working tree containing copies of the
files from the existing working tree. This is normally fine, but it
can result in a lot of unnecessary data being written to disk.

This seems increasingly relevant with AI coding harnesses. These often
use Git worktrees to let multiple agents work on the same repository
concurrently. If several agents are working on a large repository,
each worktree can result in another copy of a large number of files
being written to the SSD.

SSD storage is expensive, and SSDs also have a limited write lifetime.
It seems wasteful to physically write the same data to disk several
times when the filesystem may be able to avoid doing so.

# Proposed solution
Where the filesystem supports copy-on-write or block cloning, could
git worktree use it when creating the working tree?

For example, Windows Dev Drives (which I use) support ReFS block
cloning. A file can be cloned without physically copying all of its
data, with the filesystem sharing the underlying blocks until one of
the files is modified.

If Git knows that the destination file will initially contain exactly
the same contents as the source file currently in the folder, it seems
like a good opportunity to use this facility.

The normal behaviour could remain unchanged on filesystems that don't
support this or when the existing file is modified or a different
version from the one that will be checked out.

# Why
This would potentially:

* reduce SSD writes when creating worktrees, extending my SSD lifespan
* reduce physical disk space used by multiple worktrees
* make creating worktrees faster for large repositories
* be particularly useful when AI agents are creating multiple
worktrees concurrently

I'm not suggesting that Git should become dependent on ReFS or any
particular filesystem. I'm wondering whether there is a suitable
abstraction for filesystem-level cloning, with
platform/filesystem-specific implementations where available.

I'd be interested to know whether this is something that would fit
with the future plans for Git, and whether there are technical reasons
why this couldn't work for worktrees?

Pete