fzf on Windows assumes UTF8 stdin, but it should assume CP_ACP stdin (current system codepage)

### Checklist

- [X] I have read through the manual page (`man fzf`)
- [X] I have searched through the existing issues
- [X] For bug reports, I have checked if the bug is reproducible in the latest version of fzf

### Output of `fzf --version`

0.55.0 (fc69308)

### OS

- [ ] Linux
- [ ] macOS
- [X] Windows
- [ ] Etc.

### Shell

- [ ] bash
- [ ] zsh
- [ ] fish

### Problem / Steps to reproduce

1. Use any system codepage other than 65001 (which is Beta and is never the default).
2. Run `dir | fzf` when any file names are present with non-ASCII characters.

Result = fzf interprets the stdin as UTF8, but the stdin is never UTF8 by default, and so fzf shows garbled text.
Expected = fzf interprets the stdin as being in the system codepage by default, like native Windows programs do.

Something in fzf is going out of its way to assume UTF8 stdin on Windows, but that isn't how Windows programs work.

Ideally fzf would assume system codepage by default, and could have something like a `--utf8` flag to select assuming UTF8 stdin.

Start by reproducing `dir | fzf` on Windows with a non-65001 system codepage and non-ASCII filenames. Trace fzf's Windows stdin handling and determine how its input encoding is selected. Done means the default input is interpreted using the system codepage, with an explicit way to select UTF-8 if implemented.

Written by the indexing model from the issue text.