Unmerge the Feature-Policy and Permissions-Policy headers

[ddbeck]

Summary

This PR breaks the "alternate name" Feature-Policy into its own feature entries. See #25950 for further discussion.

Test results and supporting details

There are a few issues I have not resolved:

• Should we track the individual features/permission names under Feature-Policy, Permissions-Policy, both, or neither? I've (tentatively) tracked them in both, to preserve the continuity of many of the permissions existing before Permissions-Policy.
• Should the Feature-policy features link to any MDN pages (since they're actually for PP)? As a matter of convenience, I did not remove the links from the FP file, but I could do so.
• Should the Feature-policy features link specs? As a matter of convenience, I did not remove the links from the FP file, but I could do so.

Related issues

• Permissions-Policy - Wrongly subsumes Feature-Policy #25950

[github-actions]

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

[caugner]

• Should we track the individual features/permission names under Feature-Policy, Permissions-Policy, both, or neither? I've (tentatively) tracked them in both, to preserve the continuity of many of the permissions existing before Permissions-Policy.

Yes, I think it make sense to track them in both.

• Should the Feature-policy features link to any MDN pages (since they're actually for PP)? As a matter of convenience, I did not remove the links from the FP file, but I could do so.
• Should the Feature-policy features link specs? As a matter of convenience, I did not remove the links from the FP file, but I could do so.

This is tricky: On the one hand, I don't think that we should link to PP here, but on the other hand it provides valuable context and doesn't really cause any harm. So maybe let's keep?