windows: Make git update work

[CharlesChen0823]

when introduce SanitizedPath for deal with nuc path in windows platform. IMO, we can also using it in fs::canonicalize and fs::watch in windows platform. It will make git update checkout work in windows.

@SomeoneToIgnore

Release Notes:

• N/A

[SomeoneToIgnore]

Honestly, not sure at all, mainly due to no example and description of the issue this tries to solve.

I sure see

It will make git update checkout work in windows.

but which issue does it corresponds, what actions do I need to do to retest is missing.
And that oddity:

N/A or Added/Fixed/Improved ...

looks bad for a contributor who had been here for a while.

---

If I start to guess, this is related to git changes outside Zed, that cause FS changes?
That code is around the Workspace which #19727 was wrapping around with the Sanitized fix.

The discussion in that PR converged to an idea, that we fix things around the Workspace near to its code, so there's some sort of a barrier API there.

In addition to that Fs methods are sort of a "library" ones, so have to be relatively abstract and might better be close to std::fs of Rust stdlib by semantics?

This seems to be the opposite of all those ideas, so I'm not personally sure we have to change everything without any context at all.

[SomeoneToIgnore]

But that thing is a noop already for non-windows?
So we do not need to do that at all it seems and could have always used SanitizedPath::from.

[CharlesChen0823]

Personly, I only want using dunce::simplified, using SanitizedPath only because it is exists there.

[CharlesChen0823]

1. when using git checkout to switch branch, inside and outside zed with terminal will not update branch information.

That code is around the Workspace which #19727 was wrapping around with the Sanitized fix.

unc path mostly introduce by fs::canonicalize, and in fs::watch which using fs::canonicalize behind. we cannot avoid unc path only by using SanitizedPath in Workspace.

In addition to that Fs methods are sort of a "library" ones, so have to be relatively abstract and might better be close to std::fs of Rust stdlib by semantics?

I think this is right, but we cannot avoid unc path by call fs::canonicalize. and i add some comments here