Add FileSystemSyncAccessHandle data

[chrisdavidmills]

Summary

This PR adds BCD for:

• FileSystemFileHandle (already exists)
  • Add createSyncAccessHandle()
• FileSystemSyncAccessHandle
  • read()
  • write()
  • truncate()
  • getSize()
  • flush()
  • close()

In the current spec, close(), flush(), getSize(), and truncate() are specified as asynchronous — they return promises. Chrome 108 has introduced new synchronous versions of these methods, behind a flag.

Specs:

• https://fs.spec.whatwg.org/#api-filesystemfilehandle
• https://fs.spec.whatwg.org/#api-filesystemsyncaccesshandle

Test results and supporting details

Tested in Safari and Chrome with these samples:

• Async demo: https://glitch.com/edit/#!/reliable-ballistic-process?path=index.html%3A10%3A14
• Sync demo: https://glitch.com/edit/#!/scintillating-internal-crowd?path=index.html%3A10%3A13

The Gecko source code contains WebIDL for these features, preffed off by default (see https://searchfox.org/mozilla-central/source/dom/webidl/FileSystemSyncAccessHandle.webidl). I enabled the pref and tried my demos in Firefox, but they didn't work (failed silently), and I'm not sure why. So I've just left Fx support as false for now.

Other supporting pages and evidence:

• Safari blog post detailing support: https://webkit.org/blog/12257/the-file-system-access-api-with-origin-private-file-system/
• Chrome Status for the original feature addition: https://chromestatus.com/feature/5702777582911488
• Chrome status for adding the experimental sync methods: https://chromestatus.com/feature/5149644305203200

Related issues

Fixes #18065

[saschanaz]

In the current spec, close(), flush(), getSize(), and truncate() are specified as asynchronous — they return promises. Chrome 108 has introduced new synchronous versions of these methods, behind a flag.

whatwg/fs#55 made them synchronous, I wonder 102 should be marked as partial support 🤔