Fix regression in FindDevice function (introduced in newlib 2.5.0)

[ekeeke]

In newlib 2.0.0, FindDevice function was able to return proper mounted device index even if a digit was appended to the mounted device name (cf. https://github.com/devkitPro/buildscripts/blob/v20170117/dkppc/patches/newlib-2.0.0.patch#L5224)

In newlib 2.5.0, FindDevice function code was modified to apparently add some additional robustness check while keeping support for appended digit in name parameter compared to mounted device name (cf. https://github.com/devkitPro/buildscripts/blob/v20170117/dkppc/patches/newlib-2.5.0.patch#L6061)), however the additional check (dev_namelen == namelen) defeats the purpose of the two following alternate checks as name[namelen] == ':' is always true and isdigit(name[namelen]) is always false when dev_namelen == namelen is true.

This change can cause a problem in case of homebrew application loaded from another program that supports multi-partitioning (like Wiiflow), which appends a digit to the device name when setting the loaded application path in argv[0]. libfatInitDefault function will call newlib's chdir function using that application path as it only checks that the first digits match a default device name (cf. https://github.com/devkitPro/libfat/blob/master/source/libfat.c#L185) but chdir function will fail since FindDevice will not be able to identify the associated mounted device. This leads to defaultDevice not being set in newlib and any syscall (like fopen, opendir, mkdir, etc) to fail (and eventually crash, cf. #54, ekeeke/Genesis-Plus-GX#357 and Fledge68/WiiFlow_Lite#254) when used with a relative path instead of an absolute path.

This path restores the ability that existed in previous newlibs function while trying to keep robustness when checking provided pathname parameter.

[WinterMute]

Newlib patchset is maintained at https://github.com/devkitPro/newlib/tree/devkitPPC