Improve how the request trace id is exposed by APIs

## Description
All requests against any API in Altinn 3 will get a trace id. This is a unique id that will follow the request and all additional requests being triggered from the first. All logging of both successful and failed requests will have this trace id associated with it. The only missing part in this system is how the API often fail to show this trace id to the original caller.

In this issue the goal is to ensure that the trace id is visible for a caller in as many cases as possible. This is especially important in the case of exceptions leading to a 500 - Internal Server Error response.

Do not handle all exceptions. Let the exception handling in the application middleware generate a response instead. Try-Catch statements without any actual exception handling will in many cases be unnecessary. The general idea is documented [here](https://docs.altinn.studio/community/contributing/handbook/back-end/error-handling/).

The trace id is automatically included in the ProblemDetails model which is the model used by a few methods in ControllerBase.

Examples:

**500 - Internal Server Error**
`return Problem();`
```JSON
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.6.1",
"title": "An error occurred while processing your request.",
"status": 500,
"traceId": "00-f53c7c8063b42649ac9b2d8a8f9f6d85-33086fb185604641-00"
}
```

**400 - Bad Request**
`return BadRequest(ModelState)`
```JSON
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
"title": "One or more validation errors occurred.",
"status": 400,
"traceId": "00-9951a95bdd56f444a9ad2c6e56d213e0-c571752c62046b42-00",
"errors": {
"Title": [
"The field Title must be a string or array type with a maximum length of '5'."
]
}
}
```

Avoid using:
1. ControllerBase.BadRequest(string/object)
This will return a serialized version of the string/object which does not include trace id.

Example:
`return BadRequest("Method actually takes an object and not a string");`
```JSON
"Method actually takes an object and not a string"
```

## Considerations
> Describe input (beyond tasks) on how the user story should be solved can be put here.

### Ops requirements
> Are there any requirements for monitoring? What is being built and what could go wrong?
> Are there any requirements related to backup?

## Acceptance criteria
> Describe criteria here (i.e. What is allowed/not allowed (negative tesing), validations, error messages and warnings etc.)

## Specification tasks

- [ ] Development tasks are defined

## Development tasks
> Add tasks here

## Test
> Add test cases here as checkboxes that are being tested as part of the changes.

## Definition of done
Verify that this issue meets [DoD](https://digdir-digitalisering.atlassian.net/wiki/spaces/T3KP/pages/5049246/Definition+of+Done) (Only for project members) before closing.

- [ ] Documentation is updated (if relevant)
- [ ] Technical documentation (docs.altinn.studio)
- [ ] User documentation (altinn.github.io/docs)
- [ ] QA
- [ ] Manual test is complete (if relevant)
- [ ] Automated test is implemented (if relevant)
- [ ] All tasks in this userstory are closed (i.e. remaining tasks are moved to other user stories or marked obsolete)

Start by reviewing the application middleware, ProblemDetails, and the ControllerBase methods mentioned in the issue, then inspect how API exceptions and 400/500 responses are currently produced. Done means traceId is visible to callers in as many responses as possible, especially 500 responses, while avoiding BadRequest(string/object) and unnecessary try-catch blocks.

Written by the indexing model from the issue text.