Can be used to retrieve the Metadata object for a named path

In several places the adafs_stat function have been replaced with this
new adafs_metadata. This allowed to avoid the construnction of the
additional `struct stat`.

pos is already set to zero in the OpenFile constructor, thus there
is no need to do that also in the OpenDir constructor

readlink write at most PATH_MAX, thus we need to support also the worst case
scenario in which all the bytes are written.

In the kernel VFS some file descriptors under /proc/<PID>/fd/ could be
links to a pipe, this is a special case in which the `readlink` function
would not work. So when we detect this case we forward to kernel

During resolution of `..` component the last slash position won't be updated.

number of matched component should be decremented only when
component that was counted as matched gets removed.

for instance when `/tmp/ext/..` gets resolved to `/tmp` we should not
decrement the matched counter cause we didn't match ext before.

when resolving path we don't want always
to resolve also the last components if it is a link. Cause in some cases
we want exactly the path of that link and not the one it points to.

lstat and readlink are some example of functions that don't want to
resolve the last link.

relativize path now accepts a file descriptor.

If fd is AT_FDCWD relative path need to be considered with respect to
the current working directory. Otherwise the path is relative to the
directory with the given file descriptor

when the resolved path is the root dir we were returning an empty string

when only PSP are given as input path '//////', we got segfault

Instead of using the more complex adafs_pread function now is possible
to use adafs_read when it is necessary to read starting from the current
file position

when size is 0 the buffer to host the path of CWD must be allocated by
us

Always store complete path as CWD instead of internal and relative ones

`tar` and other gnu coreutils are using __openat{64,}_2 variant.
We need to intercept also that apart of the main `openat` function.

StackOverflow related question [1]

[1]: https://stackoverflow.com/questions/9161116/intercepting-the-openat-system-call-for-gnu-tar

add support for path resolution, this will be used to get canonical path.

More info at `man path_resolution`