fix: support symlinks without real paths with relative paths enabled

[SuperchupuDev]

fixes #113

when investigating, i found out that the issue was caused by the following line:

https://github.com/thecodrr/fdir/blob/5a0aab5b3e108eaf677e0e39c22ff1ea03cd1a59/src/api/walker.ts#L120-L121

with relative paths on, path won't be an absolute path, and as such will be resolved in the stat call as a path relative to process.cwd(). this makes it throw an ENOENT error (unless the symlink happens to be located in process.cwd()). i fixed this by changing the declaration to make it an absolute path instead.

just fixing this line wasn't enough though, because the resolvedPath seems to always be absolute. to fix this, i did a substring transformation to a relative path (if the symlink is a file) if the relativePaths option is enabled and useRealPaths is false. the latter is because symlinks can point anywhere in the filesystem, so it should return an absolute path when that is the case.

directory symlinks with real paths sadly still do not work with relativePaths on. my plan was to make it return those as absolute paths, but that is impossible as the joinPath function is already built as the relative path implementation

since symlinks with real paths and relative paths still behave inconsistently before and after this pr, i marked in the docs that resolving symlinks with real paths is only supported if the resolveSymlinks argument is set to false

also, while working on this i found (and fixed) another bug, it looks like file symlinks were never normalized, and as such could have the wrong path separator etc. fixed this by moving the normalizePath call before the stat.isDirectory() check

[SuperchupuDev]

hi @thecodrr any chance you can take a look at this and #115 anytime soon? tinyglobby support for symlinks depends on it