Windows equality check does not guarantee uniqueness on ReFS

This issue is a bit pedantic (mostly because nobody actually uses ReFS), but while discussing file equality checks with a friend I remarked on how this crate conducts the check on Windows by calling [`GetInformationByHandle`](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfileinformationbyhandle) and checking some of its output members.

I remarked that the checks done by this crate should be sufficient considering the docs say:

>You can compare the VolumeSerialNumber and FileIndex members returned in the [BY_HANDLE_FILE_INFORMATION](https://learn.microsoft.com/en-us/windows/desktop/api/fileapi/ns-fileapi-by_handle_file_information) structure to determine if two paths map to the same target; for example, you can compare two file paths and determine if they map to the same directory.

However, he noted that the `BY_HANDLE_FILE_INFORMATION` docs state:

>The ReFS file system, introduced with Windows Server 2012, includes 128-bit file identifiers. To retrieve the 128-bit file identifier use the [GetFileInformationByHandleEx](https://learn.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getfileinformationbyhandleex) function with FileIdInfo to retrieve the [FILE_ID_INFO](https://learn.microsoft.com/en-us/windows/desktop/api/winbase/ns-winbase-file_id_info) structure. The 64-bit identifier in this structure is not guaranteed to be unique on ReFS.

i.e. for those trailblazers out there who might be using ReFS, the underlying winapi-util crate should probably be using data returned by [GetFileInformationByHandleEx](https://learn.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getfileinformationbyhandleex) and using a 128-bit identifier instead. Since the context really only matters for this crate though, I'm filing this as an issue here.

Some additional context, I used to work on the Hyper-V security team and my friend worked on the Windows Sandbox security team. I never really had to deal with untrusted file paths considering Hyper-V threat model, but he mentioned that apparently we would call `GetFinalPathNameByHandle()` with the `FILE_NAME_NORMALIZED` flag when doing security-sensitive file operations and comparing the output path. I'm not trying to suggest that the checks done by this crate shouldn't be sufficient (especially since the docs explicitly say otherwise), but now I can't help but wonder if there's a reason why we weren't checking similar info.