Fix: Handle inaccessible file paths in fileSystemSource to prevent crashes

[Matejkob]

This PR addresses an issue in the handling of file system events within the fileSystemSource function. The problem arises when the open function, used to create a file descriptor for monitoring file system events, fails and returns -1. This typically happens when the system lacks access to the specified file path, either due to permissions or other constraints. If this invalid file descriptor (-1) is passed to DispatchSource.makeFileSystemObjectSource, the application crashes.

The behavior of the open function is defined in the POSIX documentation, which states that it returns -1 when access to the path fails.

While one could argue that it's a developer error to pass an invalid URL, and I generally agree with this perspective, the liblery could be used by one to provide a functionality for users where they can access files in custom locations. This PR makes such a use case more robust by handling this situation gracefully.

[stephencelis]

Thanks for bringing this up and proposing a patch! I think we may want to raise any error more visibly in a runtime warning, but we'll discuss and let you know.

[Matejkob]

I agree that adding a runtime warning could make errors more visible. Let me know the direction you’d prefer, and I’m happy to adjust the PR accordingly!

[Matejkob]

I was also considering extending the subscribe function in the Share protocol with throws, as it seems reasonable to handle error states more explicitly—especially in cases where one can provide custom implementation that will be hosted over the internet or in other environments prone to access issues. Let me know your thoughts!

[stephencelis]

@Matejkob I think more error handling support is a direction we want to explore on our way to a 2.0 of the library, but wasn't an immediate focus for this release. Because property wrappers are kind of an indirect way to loading/saving the underlying value, there isn't a very direct way to address something like error handling, and so we're not sure enhancing the protocol for throws makes sense till the larger story is figured out.