Feat/review with submission

[PGijsbers]

Change

When retrieving a submission by ID its reviews will also be returned.
I abstained from also adding it to the listing endpoint which returns multiple submissions.
I figured the main purpose for those calls is to find submissions which need a review, so it felt unnecessary.
We can easily add it later if it turns out to be used in use cases where people want the review too.

How to Test

A new unit test is introduced that covers this.
To test it manually, process an asset through the review pipeline, and then request the submission using the submissions/v1/{identifier} endpoint.

Checklist

• Tests have been added or updated to reflect the changes, or their absence is explicitly explained.
• Documentation has been added or updated to reflect the changes, or their absence is explicitly explained. -> Documentation is auto-generated. Doesn't seem to warrant a mention in the general docs.
• A self-review has been conducted checking:
  • No unintended changes have been committed.
  • The changes in isolation seem reasonable.
  • Anything that may be odd or unintuitive is provided with a GitHub comment explaining it (but consider if this should not be a code comment or in the documentation instead).
• All CI checks pass before pinging a reviewer, or provide an explanation if they do not.

Related Issues

Closes #457

[PGijsbers]

Since the field is now only defined on the ORM class and not on the classes returned by FastAPI, we no longer need to protect it from being serialized.

[PGijsbers]

This is useful to allow a session to be alive also during the FastAPI layer, where the function's return object (e.g., Submission) is coerced into the model response (e.g., SubmissionWithReviews), which may require access to database data (e.g., submission.reviews). The alternative is always eagerly loading the reviews, but that is much worse performance-wise. We probably should rewrite some other endpoints to also use this pattern.

[Taniya-Das]

Looks good.