Support reloading directly without shell

### Checklist

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

### Output of `fzf --version`

0.61 (devel)

### OS

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

### Shell

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

### Problem / Steps to reproduce

As far as I know, the only way to reload fzf currently is by giving it a command to run in a shell and then it will read data from the shell's stdout. For most cases this is very convenient. Sometimes though you may want to programmatically control fzf at runtime from another process using the HTTP server. In this case it would be very useful to be able to tell fzf to reload directly from data you provide rather than from a shell command.

Real usecase:
I am using fzf to make a window switcher script, similar to alt+tab on windows, and am using a single instance of kitty+fzf for latency reasons. When I press alt+tab, my script tells kitty to become visible and tells fzf to reload itself with the updated window list sorted by when each window was last focused.

Right now my script is controlling fzf like so:
```python
# windows_string is null separated string representing all of the open windows
windows_bytes = windows_string.encode("utf-8")
windows_base64 = base64.b64encode(windows_bytes).decode("ascii")
await send_message_to_fzf(
f'unbind(focus)+clear-query+first+reload-sync:base64 --decode <<< "{windows_base64}"'
)
```
This works, but:
- The shell isn't really necessary since my script knows exactly what data fzf should be reloaded with.
- The script is unnecessarily tied to a POSIX-like environment.
- There is slight latency before fzf reloads itself because it needs to spawn and read from a shell which it turn needs to spawn `base64`, etc.

Something like a `reload-base64` action would enable more responsive/portable ways to programmatically control fzf.
My code would become:
```python
await send_message_to_fzf(
f'unbind(focus)+clear-query+first+reload-base64:{windows_base64}'
)
```

This is probably one of those use-cases that is niche enough that it isn't worth the added complexity but I thought I would suggest it anyway.

The issue concerns fzf's existing reload-sync action and HTTP server control path; start by tracing how an action message reaches reload and how input is currently obtained from a shell. Define the direct-data reload behavior for the supplied base64 or null-separated data, then verify that runtime reload works without spawning a shell and preserves the requested ordering and query reset behavior.

Written by the indexing model from the issue text.