Add/fix several recipes (numpy, cryptography, libthorvg, vosk, srt, wikipedia + more)

[Krozark]

A batch of recipe additions/fixes accumulated while building a Kivy/KivyMD Android app against a fairly large, varied dependency set. Split into logical commits; happy to split into separate PRs if preferred.

numpy: bump v2.3.0 -> v2.3.5

Fixes an NDK/libc++ build failure (missing <unordered_map> include) present in v2.3.0's meson build.

cryptography: fix cross-compiling cryptography-cffi's build.rs

The cryptography-cffi Rust crate's build.rs needs the target Python's include dir to compile the cffi-generated _openssl.c, and needs a working C compiler for its target. Two fixes to RustCompiledComponentsRecipe make this work generally, not just for cryptography:

• get_recipe_env() now also sets a per-target CC_/AR_ pair (in addition to the existing CARGO_TARGET_*_LINKER): crates using the cc crate in their build.rs fall back to guessing --target= from the Rust triple without it, which for some targets (e.g. armv7-linux-androideabi) produces an invalid triple, picking up the wrong <limits.h> and breaking CPython's LONG_BIT sanity check in pyport.h.
• MesonRecipe.ensure_args() no longer mutates the inherited class-level extra_build_args list in place, which would otherwise bleed one recipe's meson cross-file args into unrelated PyProjectRecipe subclasses sharing the same class attribute.

cryptography's own recipe gets a small patch (via a new P4A_PYTHON_INCLUDE_DIR env var read from build.rs) to prefer the target's include dir over introspecting the host Python for it.

libthorvg: fix libomp.so glob for both lib/clang and lib64/clang NDK layouts

The glob only matched one of the two directory layouts different NDK versions use, raising a bare IndexError when it found nothing instead of a clear BuildInterruptingException.

vosk: fix Android runtime crash; add srt, wikipedia recipes

vosk imports srt unconditionally (not just from its optional CLI tool), and srt has no wheel on PyPI -- without a recipe of its own it was silently dropped, and the app crashed at runtime with ModuleNotFoundError. Same story for wikipedia, a plain build blocker (pip install has nothing to build it with, no wheel on PyPI either).

vosk also needed:

• open_dll() patched to recognize sys.platform == "android" (only "linux" and a few others were recognized, so vosk's own bundled native library loader didn't find itself on Android)
• --upgrade --force-reinstall on its own pip install step, since a pip install . with a stale but present install can otherwise no-op ("Requirement already satisfied") instead of picking up a rebuild.

recipes: add/update several generic recipes

New recipes: bitstring, libonnxruntime, lifxlan, MarkupSafe, materialshapes, meteofrance-api, mpmath, murmurhash, onnxruntime, preshed, pydantic, pywizlight, sherpa-ncnn, sherpa-onnx, simplemma, spacy, srsly, sympy, thinc, tibs, kivymd, blis, cymem, jsonschema.

Updates: freetype-py (fall back to distutils when needed), liblzma, pycairo (meson patch), regex -- version/patch bumps picked up while building against this set of recipes.

Testing

Every recipe here has been exercised by a real, full clean Android build (arm64-v8a + armeabi-v7a) of a Kivy/KivyMD app with a fairly large dependency set (the app also uses sherpa-onnx, vosk, cryptography, numpy, kivymd, and several of the newly-added recipes directly) -- BUILD SUCCESSFUL, APK installs and runs correctly on-device.

[T-Dynamos]

Please consider porting all recipes to PyProjectRecipe (or something based on it) and some of the recipes are not required.

[Krozark]

Thanks for the review! Went through every recipe added here against PyPI:

Recipes dropped (8): not required

materialshapes, meteofrance-api, mpmath, pydantic, pywizlight, simplemma, sympy, tibs — all ship a universal (py3-none-any) wheel, and (checked via requires_dist) none of their own dependencies need native compilation or lack a wheel either. A recipe adds nothing over listing them in requirements (or another recipe's python_depends), same as colorama/certifi/idna/urllib3 etc. already are. pydantic-core (the compiled Rust part pydantic pins) already has its own recipe.

Recipes kept despite also having a universal wheel themselves

• jsonschema — needs rpds-py, Rust-compiled, no universal wheel, no recipe.
• bitstring — current PyPI releases need bitarray + tibs, both compiled; this recipe exists to pin the last version that doesn't (3.1.9), not to build anything.
• lifxlan — pulls in bitstring unconstrained in its own setup.py. Without this recipe (or without the --no-deps fix in Build: Pyrex error #7 carving out an exception), pip would resolve a bitstring version needing bitarray, which doesn't build/run correctly cross-compiled here — this is the exact crash (wrong-arch .so, dlopen failed: ... EM_X86_64 ... instead of EM_AARCH64) hit and fixed building the app this PR is drawn from.

Porting to PyProjectRecipe

Reasonable direction in general (already done that way for numpy/onnxruntime here). Of what's left:

• kivymd is pinned to a dev commit (not a PyPI release) + carries a patch — PythonRecipe's plain pip install . already does the job for a pure-Python package like this.
• The rest (MarkupSafe, murmurhash, preshed, srsly, thinc, spacy, blis, cymem) are Cython packages currently on CompiledComponentsPythonRecipe. Porting each to PyProjectRecipe is plausible but I'd rather not do it blind — I don't have a way to verify all of them cross-compile correctly through that path without a full rebuild+on-device test per recipe, and CompiledComponentsPythonRecipe is what's actually been exercised end to end here. Happy to take a pass at specific ones if you'd like, or leave it as noted follow-up work.

libonnxruntime and sherpa-ncnn/sherpa-onnx aren't Python package recipes at all (plain Recipe, CMake-built shared libraries), so they're outside the scope of this either way.