Add a utility for determining the display of users on a request

[brycekbargar]

In discussing the expected interactions between requesters and proxies it turns out that it is rather complicated. Display of the Proxy user information depends on the Requester information. There's also a quite complicated interplay between the requesterId and requester properties in determining whether a user is anonymized or unknown.

Previously #1336 and #1337 were opened and iterated upon. Based on new information learned about the feature I thought it might be easier to start fresh with a different approach.

Purpose

Requests will be able to be anonymized soon. The current UI does not break when this happens but displays Unknown instead of Anonymized. This PR is intended to keep the display of requests consistent with what is actual stored.

Approach

The first step is to take all of the necessary context in one place to determine the eventual display of requesters and proxies. If this approach is accepted the code to actual use the computed will be implemented.

Refs

Screenshots

Pre-Merge Checklist

Before merging this PR, please go through the following list and take appropriate actions.

• I've added appropriate record to the CHANGELOG.md
• Does this PR meet or exceed the expected quality standards?
  • Code coverage on new code is 80% or greater
  • Duplications on new code is 3% or less
  • There are no major code smells or security issues
• Does this introduce breaking changes?
  • If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
  • There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

• What other modules will these changes impact?
• Do JIRAs exist to update the impacted modules?
  • If not, please create them
  • Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
  • Do they have all they appropriate links to blocked/related issues?
• Are the JIRAs under active development?
  • If not, contact the project's PO and make sure they're aware of the urgency.
• Do PRs exist for these changes?
  • If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.