Also bump up openssl version

Anaconda has packages that override at least sed
Greadlink is also a critical executable if present

[no ci]

This PR corrects a small but important detail in the documentation regarding how the system searches for executable files. The original text incorrectly stated that the operating system performs this search. The corrected text clarifies that it is actually the shell that performs the search.

Add script to install graalpy development builds

since we're only interested in the output when something goes wrong

* Add CPython 3.13.0b1
* Use OpenSSL 3.3.0

---------

Co-authored-by: Ivan Pozdeev <vano@mail.mipt.ru>

* Add CPython 3.14-dev
* Update 3.13-dev branch to 3.13
* Use OpenSSL 3.3.0

Signed-off-by: cuinix <915115094@qq.com>

Co-authored-by: binbjz <binbjz@skiff.com>

Add new miniforge and mambaforge definitions

Use Homebrew in Linux if Pyenv is installled with Homebrew

Cause 403s on dependency packages

We always detect missing build scripts for `4.13.0-0` because the
release[^1] doesn't have any mambaforge artifacts. Given that we've
already created the build files, we don't need to check the release
again.

[^1]: https://github.com/conda-forge/miniforge/releases/tag/4.13.0-0

The glob pattern we were using was too permissive and detecting
miniconda build scripts as miniforge build scripts when they shared the
same version. I have rewritten the pattern matching code to ensure we
only look at files starting with `miniforge` and `mambaforge`.

I was attempting to run the script to generate build files for new
versions, but it failed because version `23.1.0-4`[^1] contained a
malformed `.sha256` file.[^2] I looked at the miniforge repo's script
`releases.py`[^3] and copied the logic about which release artifacts
should be skipped when generating a list of downloads.

[^1]: https://github.com/conda-forge/miniforge/releases/tag/23.1.0-4
[^2]: https://github.com/conda-forge/miniforge/releases/download/23.1.0-4/Miniforge3-uninstaller-patch-Windows-x86_64.exe.sha256
[^3]: a15762906b/docs/releases.py (L35-L36)

In exceptional cases (custom installation, malfunctions elsewhere), `pyenv-commands --sh` may return nothing.
In non-Fish, this would cause "syntax error near unexpected token `)'" in `pyenv()`.

Bash does not allow to specify a `case` option that would never match.
This works around it by defaulting to `/`. Commands, being filenames, can never match it.
In Fish, nothing needs to be done: it apparently does interpret a `case` without argument as one that never matches.

This reverts commit 932dc464f5.

Co-authored-by: Edgar Ramírez Mondragón <16805946+edgarrmondragon@users.noreply.github.com>