Protect the catalog cache internals from external mutation

[MrCreosote]

Description of PR purpose/changes

The catalog cache exposes the cache internals by reference when returning job requirements, which means that any modification of the returned value modifies the cache. The job requirements resolver does exactly this for CSV formatted client group info from the catalog, popping the client group from the front of the list. This means that for any given app, the first run works normally and any later runs see an empty requirements set if only the clientgroup is specified, or a corrupted requirements set if there are more key/value pairs after the client group.

This PR prevents alteration of the cache by an external client.

Jira Ticket / Github Issue

• [n/a] Added the Jira Ticket to the title of the PR e.g. (DATAUP-69 Adds a PR template)

Testing Instructions

• Details for how to test the PR:
• [x] Tests pass in Github Actions and locally
• [x] Changes available by spinning up a local test suite

Dev Checklist:

• [x] My code follows the guidelines at https://sites.google.com/truss.works/kbasetruss/data-upload-project/development
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [n/a] I have made corresponding changes to the documentation
• [?] My changes generate no new warnings - 3k warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes
• [n/a] Any dependent changes have been merged and published in downstream modules
• [x] I have run Black and Flake8 on changed Python Code manually or with git precommit (and the Github Actions build passes)

Updating Version and Release Notes (if applicable)

• [n/a] Version has been bumped for each release
• [n/a] Release notes have been updated for each release (and during the merge of feature branches)