[Sketch] openat, fsync, and sync

[milseman]

No description provided.

[milseman]

This is close to being mergeable, but still has the global system call design question as #33

[lorentey]

💯 🚢

[lorentey]

Nit: we should not use prepositions as variable names.

Suggested change

	/// - at: if `path` is relative, treat it as relative to this file descriptor
	/// - base: if `path` is relative, treat it as relative to this file descriptor

Or we could just call it fd.

[lorentey]

Suggested change

	at: FileDescriptor,
	at base: FileDescriptor,

(etc, throughout this PR.)

[rauhul]

@milseman @lorentey Do we want this to be called open(_:at:...) or open(_:relativeTo:...). Whatever precedent is set here should be followed by my fstatat functions

[lorentey]

I'd be happy with either option! I like relativeTo:, too.

[milseman]

I much prefer relativeTo: personally as well, as I otherwise would do a double-take in the man page or docs to make sure at means what it means in openat(2).

edit: Oh right, that is ignored if the incoming path is absolute. FilePath has a nice API for relative and absolute paths, but I don't think we should go overboard here. We could assert/precondition the path is relative, silently pass on to openat, etc. Thoughts?

edit 2: The existence of AT_FDCWD makes me think we should give a teeny tiny bit of API polish here