Don't display foreign keys in data output

[MRichards99]

Description:
In the DB backend, foreign keys are returned in the response body of a GET request. Example for http://{{datagateway-api}}/datasets?limit=1&include="sample":

[
    {
        "id": 1,
        "complete": false,
        "createId": "user",
        "createTime": "2011-01-29 06:19:43",
        "description": "Long bed after near eye wrong. Develop Mr everybody common.\nDemocrat until stock southern song. Close face test which summer.",
        "doi": "0-467-23440-X",
        "endDate": null,
        "location": "/million/young.mp3",
        "modId": "user",
        "modTime": "2008-10-15 12:05:09",
        "name": "DATASET 1",
        "startDate": "2000-05-07 00:00:00",
        "investigationID": 1,
        "sampleID": 1,
        "typeID": 1,
        "sample": {
            "id": 1,
            "createId": "user",
            "createTime": "2011-01-29 06:19:43",
            "modId": "user",
            "modTime": "2008-10-15 12:05:09",
            "name": "SAMPLE 6",
            "investigationID": 6,
            "sampleTypeID": 10
        }
    }
]

The foreign keys shouldn't be displayed on output as they're not displayed on the ICAT backend - this is part of the work for #213.

As a note, there could be some cases where the helper functions that fetch results from the database are used as an input into another function (updating data perhaps). The ICAT backend uses similar design, so a flag might be required to distinguish the two use cases (no foreign keys GETs and foreign keys for DB input). Not 100% sure on this, but something to keep in mind.

Acceptance criteria:

• Foreign keys shouldn't be displayed GET, POST or PATCH requests involving entities that have relationships with other entities

[MRichards99]

Unassigning myself as this won't be tackled in the short term.

[MRichards99]

Adding the wontfix label to this issue - there's no plans to work on this issue for the time being and because the DB backend won't be used in production, this is a low priority, potentially high effort issue.

[MRichards99]

DB backend to be removed as per #489