Add more spec_urls; set some standard_tracks to false (APIs A-E)

[Elchi3]

This is a bit of a test PR to see if we could add spec_urls everywhere (especially for behavioral sub features).
Some things came up where we should probably agree on spec_url consistency for a few common sub features:

• worker_support
• iterable sub features (forEach, keys, values, iterator, etc)
• secure_context_required
  I decided to use the spec_url for the interface itself, happy to hear other thoughts.

Also, I think when a sub aspect of e.g. a method is described then it is okay to link to the same spec section as the method. So, basically the sub feature gets the same spec_url as the parent feature.

I marked standard_track false for a few things: CSSPrimitiveValue, CSSValue, CSSValueList, DOMError, FeaturePolicy. Doesn't look like these will be going anywhere.

Fixes #27456.

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[caugner]

Some exploratory thoughts:

• Could we remove spec_urls identical to the parent in the built data.json? (This way, we can still validate, but keep the published data concise.)
• What if we changed the data to spec: { url: "…" }, allowing spec: "inherit" and spec: { pr_url: "…" }? (Doesn't mean we have to change the published data.)

[Elchi3]

The goal for having a spec_url is to be sure that the BCD feature points to something that is real and standardized. We already have several BCD features pointing to the same spec_url. I don't understand why it would be desirable to introduce additional complexity (neither from the authoring side nor from the publishing side).
From a published data point of view, my sense is that always having a spec_url would be great for consumers. And if there isn't one, it means the feature is not specified anywhere. That goal is also formulated in #1531.

[caugner]

This is a bit of a test PR

Is it okay to merge?

[Elchi3]

This is a bit of a test PR

Is it okay to merge?

Yes, thanks for taking a look! I will proceed with more additions like this given that no one seems to hate it :)

[caugner]

Let's mark as draft for now then, I'll happily go through the changes to double check once complete.

[github-actions]

This pull request has merge conflicts that must be resolved before it can be merged.