GithubImporter: Refactor the Representation layer
<!--IssueSummary start-->
<details>
<summary>
Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards.
</summary>
- [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=330331)
</details>
<!--IssueSummary end-->
### Problem to solve
If we compare the github importer with an ETL architecture, like GitLab Migration (`BulkImports`) the representation layer would be the `T`, the layer responsible for transform data from the source to be used in the **L**oaders (layer that saved the data). But, currently, the transformation is being leaked to the `Loaders` layer, [example](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/github_import/importer/diff_note_importer.rb#L24). That's happening because the representation objects receives too little _context_ of the importer, for instance it doesn't have access to what project is being imported which is required to build some data.
### Representations
- [ ] Gitlab::GithubImport::Representation::DiffNote
- [ ] Gitlab::GithubImport::Representation::Issue
- [ ] Gitlab::GithubImport::Representation::LfsObject
- [ ] Gitlab::GithubImport::Representation::Note
- [ ] Gitlab::GithubImport::Representation::PullRequest
- [ ] Gitlab::GithubImport::Representation::PullRequestReview
- [ ] Gitlab::GithubImport::Representation::User
### Proposal
- [ ] **optional** Rename the `Represenation` classes/namespace to `Transformers` to express better its intent and use a similar vocabulary to the GitLab Migration (`BulkImports`);
- [ ] Pass more context to the Transformers, like the `project` being imported and the `client` being used. Similar to the `BulkImports`, a `Context` class could be created to hold this information; (https://gitlab.com/gitlab-org/gitlab/-/merge_requests/72429)
- [ ] Remove some of the duplication among the `Transformers` by adding either a super class or a mixing with the shared behavior;
- [ ] Define a clear public API for all `Transformers`, something like `#transform` (again following what's being used in `BulkImports`
### Expected results
- Better maintainability due to
- Simplified Representation/Transformation layer
- Simplified Loader/Saving layer
issue