ffmprovisr structure: code modularity for better organisation, multilingual support, etc

In the past, we've had some discussions that relate to the technical structure of ffmprovisr:
- https://github.com/amiaopensource/ffmprovisr/issues/309
- https://github.com/amiaopensource/ffmprovisr/issues/416
- https://github.com/amiaopensource/ffmprovisr/pull/485#issuecomment-3684157570

I'll pull over some parts of my comment on the español translation (the third link).

Currently, all recipes are in a giant HTML file. To add a new one, you simply cut and paste the template, uncomment it, and fill it out.

Pros:
- no compilation step: you can simply open the HTML file in the browser
- easy and user-friendly to contribute to

Cons:
- we cannot easily support multiple languages
- the HTML file is very long and unwieldy
- the current approach may lead to a lack of consistency.

In the past (~5y ago) I was in favour of keeping it simple, but now I would more support a modular approach with these features:
- individual recipes in standalone files
- could be JSON, YAML, React components
- a compilation step that outputs an HTML file like the current.

I'd be willing to do the dev work to achieve this, though would def want support with code reviews and discussion.

I'd like to hear from the other maintainers (and indeed, anyone else who wants to weigh in):
1. What do you think about how we should structure ffmprovisr going forward?
2. If we refactor to a different approach, do you have any thoughts about which tech to use?

cc @ablwr @kieranjol @privatezero @retokromer @ross-spencer