Tasktype endpoint should gracefully handle malformed api_constraints values

[aayush-0131]

Describe the bug
The /tasktype/{task_type_id} endpoint is not robust to unexpected api_constraints values.
In src/routers/openml/tasktype.py, the current parsing assumes a valid JSON string containing data_type. If api_constraints is malformed JSON, already a dict, or missing data_type, the endpoint may fail or behave inconsistently.

To Reproduce
Minimal reproducible setup (data-level reproduction):

1. Ensure a task type exists with at least one input row in the DB.
2. Set api_constraints for that input to malformed JSON, for example:
   • "{bad json"
3. Call:
   • GET /tasktype/<task_type_id>

Also test with:

• api_constraints already stored as a dict/object-like value (if DB layer returns dict)
• api_constraints valid JSON but without data_type, e.g. {"foo":"bar"}

Expected behavior

• The endpoint should return a stable response and should not crash.
• It should accept both legacy JSON strings and dict-like values.
• It should include input[].data_type only when data_type is present.
• Malformed JSON in api_constraints should be ignored gracefully for that field.

Additional context
Proposed fix is to make parsing defensive:

• parse string values via json.loads inside try/except json.JSONDecodeError
• accept dict values directly
• set data_type conditionally using safe lookup

[PGijsbers]

As discussed on the initial PR in this comment failure should not be graceful in the sense that the user shouldn't notice it happened at all. Having invalid JSON as part of the task type definition is a critical error that should be caught as soon as possible. However, the current implementation doesn't give a very useful error to the end-user. We could give the user an error indicating the nature of the issue, and that we have to fix it in the server.