support data formatting via pliers

[jeremymanning]

Pliers is a fantastic looking toolkit for converting a wide variety of data formats into feature vectors. This seems like a perfect sub-routine for hypertools, e.g. via the format_data function. Idea:

• User passes in messy data in mixed formats
• Inside format_data we:
  • Group "like" data (e.g. text with text, images with images, numbers with numbers, etc.). This is tricky...we first need to come up with an appropriate set of categories. (E.g. does audio count as "text" because we can apply speech-to-text on it? Or does it count as a matrix like any other? Or a separate audio category? And who makes that decision? And if we make that decision for users, will it be user-controllable?)
• convert all data within each group into numpy arrays, using pliers as needed/appropriate
• return a list of numpy arrays

[jeremymanning]

Not addressed in the HyperTools 1.0 update (PR #272, #272): pliers is not a dependency and format_data has no multi-modal type-detection/dispatch layer.

How this could be built on the 1.0 architecture: hypertools/tools/format_data.py already dispatches numpy/DataFrame/text inputs. The cleanest extension mirrors the existing text2mat.py pattern (a dedicated <modality>2mat converter with a small model registry) rather than the Manipulator/manip base-class+funnel pattern, since this is an input-conversion step, not a transform on already-numeric data. Concretely: (1) add a lightweight modality classifier (text / image / audio / numeric) ahead of the existing dispatch in format_data, (2) add optional image2mat/audio2mat modules alongside text2mat.py, each with a registry dict resolved the same way vectorizer_models/texts are today, (3) make pliers (or alternatives) an optional extra in pyproject.toml (e.g. hypertools[multimodal]), imported lazily like reduce.py already does for UMAP.

Alternatives / prior art:

• pliers (github.com/tyarkoni/pliers) — still maintained (pushed 2024-04, 56 open issues, not archived), but heavy: pulls in many per-modality extractor dependencies (audio, video, image, APIs).
• Lighter 2026-era alternatives for the same goal: Hugging Face transformers/sentence-transformers feature-extraction pipelines for image/audio embeddings, librosa for audio features, torchvision/CLIP for images — smaller footprint than pulling in all of pliers.
• HyperTools already has a working text path (text2mat.py); only image/audio are genuinely missing.

Note: the issue's open question ("who decides the modality taxonomy, and is it user-controllable?") is still unresolved and is really a design decision, not an implementation detail — worth settling before writing code.

Tagging as high effort; leaving open for consideration in a future release.