Diversify branding for a broader scope of applications

[phseiff]

Currently, gender*render is branded as a tool mainly for rendering email templates, and analogously, the spec is branded as a proof of concept that gendering people in automated emails is possible. I feel, however, like this misses a relatively big branch of applications, these being text dialogues in computer games (mainly RPGs and visual novel).

As it is now, most computer games offer only two genders (with binary pronoun preferences) to play, though this is admittedly more of a social and/or historical issue, whilst actively progressive games offer a non-binary option with gender-neutral they/them pronouns. There are, however, as far as I know (feel free to correct me on this) no games where the player can customize their pronouns, which I feel would be necessary to make games inclusive, though admittedly out of the technical scope of lots of game companies. Branding gender*render for the purpose of gendering procedurally generated/ displayed dialogue in games and other products in addition to correctly gender emails would therefore be appropriate and add a possibly even more common use case to gender*render's portfolio, as well as broaden the scope of problems it "proofs" to be solvable.

I admit that replacing every mention of "emails" with "emails and video game dialogue" would be cumbersome and bloated, but at least the first mention of "automatically generated emails" in every prominent document (that is, those documents including gender*render's vision, which is mainly the spec and the README) should be extended to procedurally generated dialogue.

I could also imagine a section in the specification's introduction about this use case (like the introduction I gave above) in addition to the section explaining the use case of automated emails.

I think I will do this once I get to work on a general wording overhaul for the main specification, which is worded somewhat messy here and there right now due to lots of changes applied to it during its initial development, but before I get to do this, I will have to work on some things at hand (the issues labelled with needed) and, in the process, potentially reevaluate which spec/ extension spec some features belong into and flesh out the way the spec, extension specs and semantic versioning flow with each other.

[phseiff]

I actually did this already right now, since this repository is getting a surprisingly high amount of traffic at the moment and therefore needs to be presented in the best and most authentic way possible (see this commit).
The additions made to the abstract of the specification are present in v0.1.1 of the specification.