This is a proof-of-concept for #182. It simply clones the Core users controller, but then strips out all the endpoints except the read access ones. The single user endpoint takes a slug instead of a numerical ID. The multiple users endpoint requires adding the slug query parameter and listing the specific user slugs you want to retrieve.

Additionally this controller limits the request context to either view or embed (omitting edit) so that only data fields that are already public are available in the response.

Another thing we could do here is add in some fields specifically from profiles.wordpress.org. Things that are viewable at a user's public profile page, like their bio, whether they are sponsored, maybe their badges?

To test

1. Best to do this on a wporg sandbox.
2. Upload the files and then while sandboxed, go to https://wordpress.org/wp-json/wporg/v1/users/{your wporg user slug} in your browser.
3. Try adding the context parameter ?context=embed. That should show identical info to the default response. Changing embed to edit or anything else should give you an error message.
4. Now try going to https://wordpress.org/wp-json/wporg/v1/users?slug={your wporg user slug}
5. It should be the same as the first endpoint, except returns an array with one item.
6. Try adding other user slugs, separated by commas.
7. Compare the data shown to something like https://wordpress.org/wp-json/wp/v2/users. It should be all the same fields.
8. Trying to retrieve user data via fields other than slug (e.g. id) shouldn't work.