Make access check algorithms no longer associated with an entry

[a-sully]

Access checks are currently tied to a "file system entry". As of #96, a "file system entry" now corresponds to an actual file or directory on disk. We need to support access checks on FileSystemHandles which don't correspond to an entry (e.g. the entry has been removed), so the access checks must be tied to something else.

We could tie access checks to a FileSystemHandle or a "file system locator". See #96 (comment)

[annevk]

@mkruisselbrink's comment is the one we need more clarity on I think:

Related to my comment above on tying access checks to paths, the current chrome implementation (at least last I looked at it, which admittedly is a while ago, so maybe that has been changed already?) does not guarantee that two handles representing the same path behave the same in all aspects (since for handles acquired via DirectoryHandle.getFileHandle/getDirectoryHandle the access checks are done with the path of the original directory, rather than the path of the current handle).

I'm not saying that shouldn't be changed, but it's certainly something to keep in mind. Perhaps tying access checks to the FileSystemHandle rather than the entry would be a way around that, if we want to keep the same behavior? Although you'd have to figure out how to serialize that properly as well.

Although maybe this already works as we simply share query access and request access with newly created children so they would all end up using the same path.