Introduce singular capabilities for managing individual options

[flixos90]

We've always had manage_options, but it's currently impossible whether a user can manage a specific option. As part of related tickets dealing with more granular capabilities (see https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&keywords=~granular-capabilities&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&col=component&order=priority), I suggest adding a meta capability manage_option.

It should accept (or basically require) the option name as argument. By default it should fallback to the regular manage_options, but an auth_callback could be passed to register_setting() to tweak the permissions there (such an auth_callback is already known from register_meta()).

This would also be useful for the REST API so that it can use the more granular permissions.

[flixos90]

43210.diff​ provides an example implementation for the suggested approach.

[flixos90]

Somewhat related: #38734 could also make use of that for determining whether to display the individual fields and update their options.

[dlh]

A singular capability for managing individual options seems to me like a great enhancement. However, I'm not sure I understand the behavior of the filter in 43210.diff​, if I'm following it correctly.

It's described as filtering "whether the user is allowed to manage an option." But if the value of $allowed is filtered to true, the user isn't necessarily allowed to manage the option, as they still need manage_options. If the value of $allowed is false, the user isn't necessarily blocked from managing the option, at least in the way they would be with do_not_allow. Instead, they just need another capability.