Refactor the catalog search form's org-select component for separation of concerns

[Jane Sandberg]

As part of bug 2032665, I will be creating a separate org selector component for the staff catalog search form. It will ultimately differ from the current org selector with 2 new features: the ability to hide certain org units, and the inclusion of shelving location groups.

In the meantime, though, my goal is to simply match the functionality of the org-select in the context of this form. It should behave completely the same from a user's perspective, but the code will differ in a few ways:
* Greater separation of concerns between org unit data parsing vs. data display vs. user interactions
* A high level of unit test coverage
* It does not contain org-select features that are not needed in the catalog search form

These three characteristics should hopefully make it quite a bit easier to implement the aforementioned functionality.

This is part of an overall project I'm working on with NOBLE, which is described here: https://docs.google.com/document/d/1Aioe5GfQXHXrWVF90r_xdsbMhm1PjHP1vFOyyO0R3DY/edit

Branch coming soon.

[Jane Sandberg (sandbergja)]

Here is the branch: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/sandbergja/lp2062917-refactor-staff-catalog-org-select / user/sandbergja/lp2062917-refactor-staff-catalog-org-select

Testing this is a little awkward, since you have to essentially prove/disprove a negative. The goal is that no behavior changes on the catalog search org select, and I sure would appreciate help seeing how true that is. :-)

Noting also that this branch has similar vibes to bug 2054233 -- disentangle part of the org-select functionality for a specific use case so we can improve it later -- although they are looking at different use cases.

Not adding pullrequest at the moment, to give NOBLE (who sponsored this work) a chance to review and test it first.