Organize new tokens/entities

Currently, all tokens exported from Coda (apart from the duplicate ones) are defined here:

https://github.com/Devographics/entities/blob/main/tokens/pain_points/html_pain_points/new_pain_points.yml

Beyond the fact that a single huge list of 300+ items is harder to manage, there are many items which are simply not pain points, such as

https://github.com/Devographics/entities/blob/main/tokens/pain_points/html_pain_points/new_pain_points.yml#L2026

```
- id: webusb
name: |
WebUSB API
parentId: apis_capabilities
```

This is a browser API, and should be defined in this file (for example):

https://github.com/Devographics/entities/blob/main/entities/features/html_features/html_main.yml

As well as follow the same general structure as for example the Web Share API:

```
- id: web_share_api
webFeaturesId: share
name: Web Share API
needsTranslation: true
description: Exposes a mechanism for sharing content to various user-selected targets.
descriptionIssues: >
Issues related to the Web Share API for invoking the native sharing
capabilities of the device.
parentId: apis_capabilities
example:
language: js
code: navigator.share(shareData)
mdn: en-US/docs/Web/API/Web_Share_API
w3c: TR/web-share/
resources:
- url: https://web.dev/web-share/
title: Integrate with the OS sharing UI with the Web Share API
caniuse: web-share
tags:
- features
patterns:
- share api
- navigator\.share
```

In other words:

- Move to correct file
- Use underscores in the name, so `webusb -> web_usb_api` (this helps with regex matching)
- Also do any renamings in Coda doc just to be safe, even though ideally we won't use it anymore.
- For backwards compatibility, add a `idAliases: [webusb]` field
- Add `webFeaturesId` field ([in this case](https://web-platform-dx.github.io/web-features-explorer/features/webusb/) `webusb`)
- Maybe add description, code examples, mdn, w3c, etc. links, etc. (nice to have)

---

Because there are too many entities/tokens to deal with in one go, we can prioritize those that actually appear in the survey (Any pain point question -> All pain points -> Flat view -> find the items that look like actual APIs or features).

Start by reviewing tokens/pain_points/html_pain_points/new_pain_points.yml and entities/features/html_features/html_main.yml, then identify survey-used entries that are APIs or features. Move each to the appropriate feature file, apply the requested naming, alias, and webFeaturesId conventions, and update the Coda names where needed. Done means the prioritized entries are organized without losing backwards compatibility.

Written by the indexing model from the issue text.