static: harden dot-segment check for backslashes, test non-validating custom fs.FS

[vishr]

A custom fs.FS that does not follow the fs.FS contract (for example a hand-written adapter over a directory or object store that joins names with filepath.Join) could resolve a requested name outside its root. Since v5.4.0 (GHSA-3pmx-cf9f-34xr) Echo does not open paths with a ., .. or empty segment, so a name with a .. element is never passed to Open.

Changes:

• Hardening: the dot-segment check now also rejects . and .. parts separated by a backslash (e.g. ..\secret.txt). Such a name reaches the filesystem with the default configuration via /..%5Csecret.txt or a literal backslash, and via /..%5csecret.txt when path unescaping is enabled. A backslash is a literal character in fs.FS names, and os.DirFS, embed.FS and Echo's default filesystem are not affected; but a custom filesystem that wrongly treats a backslash as a separator (such as one built on filepath.Join on Windows) would otherwise resolve it outside its root. Names containing a backslash but no ./.. part (e.g. dir\file.txt) are unaffected.
• Regression tests with a non-validating filesystem that treats backslash as a separator on every OS, for Echo.StaticFS (with and without EnablePathUnescapingStaticFiles) and the static middleware (root and group routes, with and without EnablePathUnescaping), covering literal .., %2e%2e, ..%2f, nested .., ..%5c, ..%5C, a%5C..%5C.. and literal ..\; plus unit tests for the helper. The tests fail without the change on Linux, macOS and Windows.
• Comments: middleware/static.go said the "/" prefix removes .. components (the code uses "./"; .. paths are not opened and are handled like a missing file) and referenced a non-existent static_windows.go; the helper doc now describes the backslash rule.

Changelog: static: do not open paths with a "." or ".." part between backslashes (hardening for custom filesystems that treat a backslash as a separator).