Context-dependent entity metadata (`foo` vs `foo_issues` problem)

Originally my thinking was that if we code React pain points as just `react`, we won't be able to change the description. Because it we changed it to something like "Issues with React", then that would also appear as the canonical description for React everywhere else even for charts that have nothing to do with pain points.

So my solution was to create separate `foo_issues`-type codes for the pain points so that they can have their own descriptions or other metadata.

But the downsides are:

1. This makes our codebooks larger
2. Pain point charts lose access to all existing `react` metadata (link to homepage, github, npm , etc.) unless we duplicate it to `react_issues`, which is not practical.

So the solution I now favor is:

- Only have `react`
- Find another way to have context-dependent metadata. See below.

### Context-dependant metadata

Examples:

```
- id: react
name: React
overrides:
- questionIds: [front_end_framework_pain_points]
name: React issues
description: Issues with React
```

Or:

```
- id: i18n_issues
name: Internationalization
patterns:
- translation
- locali(z|s)ation
overrides:
- id: web_components_common_pain_points
name: Web Components Internationalization
patterns:
- i18n
```

Or:

```
- id: react
name: React
overrides:
- idMatch: *pain_points*
name: React issues
description: Issues with React
```

The issue names no files, tests, or entry points. Start by locating the codebook and entity-metadata handling, then compare the proposed overrides examples against existing metadata behavior; done means agreeing on and implementing a context-dependent metadata design without duplicating entity codes or shared metadata.

Written by the indexing model from the issue text.