LLM Data Import

Some notes about importing normalization data from LLMs (cc @LeaVerou and @DmitrySharabin).

### ID Specificity

We should avoid broad `ids` such as `desktop` or `images` because they are quite vague once taken out of the context of pain points. Instead, `desktop_issues` and `images_issues` make it clear that these are pain points.

### ID Collision

Overly broad `ids` also run the risk of colliding with existing entities/tokens (https://github.com/Devographics/entities). For example `firefox` is already assigned to the Firefox browser itself. So when referring to e.g. "issues with Firefox", `firefox_issues` would be better.

### ID Continuity

There is also a backwards-compatibility aspect where if for example we've used `interoperability_issues` up to now, it'd be better to avoid switching to e.g. `interop` when referring to the same concept.

### Filtering Codes/Tokens

To make dealing with these issues easier we can probably leave out any code with less than 10 matching items from the YAML exports, since these won't show up in the survey results anyway.

### ~~Common vs Question-Specific Codes/Tokens~~

EDIT: unified file is probbaly better after all

We don't want to repeat the same codes/tokens across e.g. `forms_pain_points.yml`, `graphics_pain_points.yml`, etc. So it'd be good to factor our any common codes into their own `common_pain_points.yml` file.

**Note: this can be solved by using a single file for all pain points for a survey, but the downside is that this removes the ability to define that a set of pain points should only apply to question Foo, while another set only applies to question Bar, and so on.**

### Generic Codes

It might be better to leave out generic codes such as `limitations` or `tooling` altogether since they might make the resulting charts less specific.

### ID Formatting

Maybe it's a one-off thing but I noticed an id named `end-user_ux`. It'd be good to avoid `-` and only use `_` in IDs to be safe.