Don't rely on path_max

Hi,

Following up to my comment in https://github.com/fastfetch-cli/fastfetch/issues/1895#issuecomment-3206602801 on PATH_MAX.

I would like to get rid of the `-DPATH_MAX=4096` hack for hurd.

I had a look where PATH_MAX is used and it is used only for `realpath(3)` and `readlink(2)` to allocate a buffer that will be "big enough".

For `realpath` glibc will allocate a buffer for us with the result when the output is NULL. (this case is not specified by posix). I don't think this is something that other libcs implement though.

The man page for `readlink` also suggests to not rely on PATH_MAX and suggests to use `stat.st_size` from `lstat` and malloc a buffer manually.

The problem with this approach is that while `lstat` on `/proc` returns sensible values on hurd e.g. on linux the size is `0` so the PATH_MAX approach is still needed.

Also there are currently at least 2 `static inline realpath` aliases for windows.

terminalshell_linux has a ` FF_EXE_PATH_LEN` instead.

Before I start to make this work would it make sense to consolidate this into new helpers to not litter `#ifdef PATH_MAX` everywhere?

まず、realpath(3) および readlink(2) に関連する PATH_MAX の使用箇所をすべて見つけ、次に Windows 向けの static inline な realpath エイリアスと terminalshell_linux の FF_EXE_PATH_LEN を調べます。Hurd と Linux でのアロケーション動作を比較し、共有ヘルパーで散在する条件分岐を置き換えられるか検討してください。これらのプラットフォーム固有のパスを壊すことなく、Hurd の PATH_MAX ハックが不要になれば完了です。

索引モデルが issue の本文から書いたものです。