Fix ConvertDirent for AIX by always returning PAL_DT_UNKNOWN (dotnet/corefx#34088)

Fix ConvertDirent for AIX by always returning PAL_DT_UNKNOWN (dotnet/corefx#34088)

* Fix ConvertDirent for AIX by always returning PAL_DT_UNKNOWN

I commited the sin of untested code, as this function wasn't wired
up to Mono's BCL until a few days ago, and I had triggered the
situation where I needed this working by purging stale build
artifacts.

What happened here was me being too clever; I tried stat, but
we only have the file name, and from the unmanaged call stack this
would run in, we'd have no way to get the directory it's in
(without butchering the function signature) to properly use stat
for non-cwd directories. This meant that the check would get random
garbage on the stack; sometimes the data for "..", sometimes
another function would clobber it, and it'd read that. This caused
the Mono gensources tool to act erratically, preventing the BCL
from building.

Fix this by always returning DT_UNKNOWN. This isn't ideal, but the
BCL seems to handle this with grace and does a stat afterwards
to properly fill in data. It's enough to get the Mono build from
scratch working again. (The stat bit was verified by me running the
syscall tracing tool, `truss` over it, plus Mono's JIT trace.)

* Handle DT_UNKNOWN cases in FileSystemEntry.Initialize

On some OSes like AIX, we return DT_UNKNOWN as a sentinel value,
because they don't have a type field in dirent. If so, or the OS
does return a type and we got an unknown, also set symlink status
if so when making the managed equivalent structures.

TimeZoneInfo.Unix also calls ReadDir and thus ConvertDirent, but
it does this logic already.

* Move symlink check to its own if-elif block

Commit migrated from https://github.com/dotnet/corefx/commit/c34dd2fb843c45ad135ef2b0348c06224e15c736