When the Crystal runtime encounters file related errors in system APIs it reacts differently depending on the type of error.
For example, File::Error.new_from_os_error instantiates appropriate subtypes, such as File::AccessDeniedError or File::AlreadyExistsError.

As was discovered in the process of #15901 and the discussion in #15902, the error condition of a file name being too long to handle should perhaps be considered a File::NotFoundError error.
From a user's perspective, errors ENOENT and ENAMETOOLONG both indicate the provided path cannot be accessed. The reasons are different, nonexistence or invalid path. But the errors should usually be handled similarly.
The differences should be represented in the error message, but it makes sense to group them into the same error category (i.e. class).
Currently, ENAMETOOLONG results in an unspecific File::Error.

The equivalents to Errno::ENAMETOOLONG on Windows seem to be WinError::WSAENAMETOOLONG and WinError::ERROR_FILENAME_EXCED_RANGE. However, the latter only occurs if the path exceeds even the long limit of path lengths. Anything shorter that still exceeds MAX_PATH produces ERROR_PATH_NOT_FOUND. This supports the idea of treating "path too long" the same as "file not found". The Windows API does that implicitly already.

Besides the exception class selection, this change should also affect File.info? which has separate logic to identify whether a path is not found.