Add /users endpoint to API

[eloquence]

In order to reliably update local user databases (see, for example, freedomofpress/securedrop-client#1143), it would be useful for the API to expose a /users endpoint.

Currently, non-admin users do not have the ability to see a list of all users via the Journalist Interface , so we may only want to return the UUID for each user (and potentially a property like is_deleted or is_locked if/when such functionality is implemented, cf. #5467).

[sssoleileraaa]

Just want to make a note of what bug this would currently solve. Right now, we learn whether or not a user has been deleted through the replies endpoint. If a user does not have any successful replies on the server and they are deleted, we will not learn whether or not that user has been deleted. From the client, even though the user would not be able to log in, it would look like that user has an active account. Also if that user has any draft replies that never made it to the server, those replies will continue to exist locally and will continue to be attributed to the user, which others will be able to see in the GUI.

[eloquence]

A few updates on this issue:

1. We've provisionally agreed that this would be a useful endpoint to add, either in 1.6.0, or after.
2. We would likely want to return user name, first name, and last name, in addition to the UUID, but not the is_admin flag.
3. After some back and forth, we agreed it should be called /users, to be consistent with the existing /user endpoint, and because it's more inclusive of users in different roles in an org.
4. In terms of additional disclosure of user information to non-admins, while non-admins can't currently enumerate all users, they can enumerate many users, since the /replies endpoint discloses the same user data which would be provided by this endpoint, for users who have sent replies.
5. Once this lands, in a future release, we could consider removing the full user data from the /replies endpoint (returning only the UUID of reply authors). This should only be done once the production release of the SecureDrop Client no longer relies on it.

I've raised my hand for putting together a PR for this issue, and then we can reason a bit more about 1) any additional impact in the context of our threat model, 2) whether or not this should land in 1.6.0.