Clarify class-ownership of 1) data retrieval, 2) packaging of data, 3) queueing of data

Problem/Motivation

There are four distinct phases to the Orange Logic integration that overlap inside the code:

1. Creating a client and calling the api.
2. Packaging the result into a consistent OrangeDam item class.
3. Queue-ing the item for migration
4. Migrating items.

Currently, OrangeDamApi is involved in steps 1-3, and OrangeDamMigrationDataManager is involved in steps 2-4. And there is also some blur around what actions OrangeDamQueueDataManager should maintain full ownership of.

This thread, from merge request 58 (issue 3439306) illustrates the issue well.

Proposed resolution

1. Discuss/clarify what operations should belong to which classes, and which points of contact need to be made and maintained as public and what can be sealed off.
2. Refactor methods to be more streamlined, doing _less_ and provide public "convenience methods" that package any multi-step operations into easily callable functionality.

3. Create new class whose sole purpose is to contain public-facing convenience methods, so that the interiors of API, Qeueue, and Migration can be made more atomic and isolated without losing the catch-all convenience of a method such as `queueContentItem()` (which retrieves (OrangeDamApi), packages (OrangeDamContent), and queues (OrangeDamQueueDataManager) items.

Remaining tasks

Conversations and sketches.

API changes

Several changes expected. Too early to tell exactly what those might be.

Alternatives

Don't refactor as a general project, but try to achieve the overall outcome, once consensus is reached, in smaller, step-by-step refactorings.