… platform (denoland#34558)

## Summary

`is_skippable_io_error` (the helper that decides which IO errors
silently get skipped while walking ancestors for a
`deno.json`/`deno.jsonc`) previously gated its checks on `cfg!(windows)`
/ `cfg!(unix)` and raw errno comparisons:

```rust
if cfg!(windows) && e.raw_os_error() == Some(123) { return true; } // ERROR_INVALID_NAME
match e.kind() {
  InvalidInput | PermissionDenied | NotFound => true,
  _ => cfg!(unix) && e.raw_os_error() == Some(20), // ENOTDIR
}
```

The same logical condition — a non-directory parent component on the way
to `deno.json`, an invalid filename, a directory that happens to be
named `deno.json` — maps to different errors on Linux vs. Windows. The
function returned `true` on one platform and `false` on the other for
what was effectively the same situation, causing discovery to abort on
one OS and silently continue on the other. That is the inconsistency
reported in denoland#17428 — a test passing on Windows because the walk-up found
a config file, while the same test on Ubuntu failed to find one (or vice
versa).

Match on the now-stable `ErrorKind` variants directly:

```rust
matches!(
  e.kind(),
  InvalidInput | InvalidFilename | PermissionDenied
    | NotFound  | NotADirectory   | IsADirectory,
)
```

`NotADirectory`/`IsADirectory` are stable since Rust 1.83 and
`InvalidFilename` since 1.87. The toolchain pinned in
`rust-toolchain.toml` is 1.95.0, so all three are available. Behavior is
now identical on every OS.

## Test plan

- [x] `cargo test -p deno_config util::` — existing
`is_skippable_io_error_win_invalid_filename` still asserts errno 123 is
skippable, added a Unix twin for errno 20, and added a portable
`is_skippable_io_error_kinds` that asserts the expanded `ErrorKind` set
is skipped on every platform (and that unrelated kinds like
`ConnectionRefused`/`UnexpectedEof` are not).
- [x] `cargo check -p deno_config`, `cargo clippy -p deno_config
--no-deps`, `cargo check --bin deno` — all clean.

Closes denoland/orchid#304

Co-authored-by: divybot <[email protected]>
Co-authored-by: Divy Srivastava <[email protected]>