runtime: Don't hardcode PATH_MAX

[Nopey]

Windows' _fullpath and _getcwd will handle allocation if we pass NULL as the buffer, but please note that this will not remove path length limitations.

Unfortunately, posix_fs.jakt is not so straightforward.
realpath: POSIX.1-2008 lets us pass NULL for the second argument, resolved_path; libc will allocate for us.
getcwd: Linux lets us pass NULL, but POSIX defines this as undefined behavior. Can and should we special-case any os/libc whose getcwd will do the allocation for us?

[alimpfard]

We could add the means to select different modules based on libc, but iirc getcwd() will return with an error if the path doesn't fit in the buffer, so we should be able to keep allocating larger buffers until it returns non-NULL?

[Nopey]

Paths over 4096 can now be returned by jakt's current_directory and real_path: We use the POSIX.1-2008 realpath behavior, and getcwd has a loop to grow the buffer size until the buffer is sufficient.

This does not mean Jakt is long path aware on POSIX, as that would require breaking paths up into relative paths that fit within PATH_MAX (which could be as low as _POSIX_PATH_MAX, 256) and using openat chaining (to implement filesystem apis that may fail on long paths such as as mkdir)

[alimpfard]

Apparently I forgot to press "comment" the last time I came to review 😅