dlt-qnx-slogger2-adapter: resource leaks and robustness issues in context-map parsing and cleanup

### Environment

- `src/dlt-qnx-system/dlt-qnx-slogger2-adapter.cpp` (and `dlt-qnx-system.h`)
- `master`, project version 3.0.1

I was reading through the slogger2 adapter and ran into a handful of issues. A couple are clear bugs, the rest is ownership and cleanup stuff that's easy to get wrong as it stands. Listing them together; happy to split if you'd rather.

### Bugs

The JSON decoder in `dlt_context_map_read` is never freed. `json_decoder_create()` allocates it but there's no `json_decoder_destroy()` anywhere, not on success, not on the early `return` after a parse failure, not on the `break` paths. So it leaks on every call ([json_decoder_destroy docs](https://www.qnx.com/developers/docs/7.0.0/com.qnx.doc.json/topic/json_decoder_destroy.html)).

In the same loop, a single bad entry kills the whole map. If descending into a context object or reading its `name`/`description` fails, the code `break`s and stops parsing everything after it, so one malformed entry silently drops all the valid contexts that follow. I think it should pop + continue and skip just the bad one.

`wait_for_buffer_space` divides by `total_size` without checking it's non-zero (`used_size / total_size`). If `dlt_user_check_buffer` ever returns a zero total that's UB. Probably want to treat zero as "full" and bail.

`clean_qnx_slogger2` deletes every `DltContext*` in `g_slog2file` without unregistering it first. The adapter's own `dltQnxSlogger2Context` does get a `DLT_UNREGISTER_CONTEXT` (in `slogger2_thread`), but the per-name contexts registered from the JSON map via `dlt_register_context` are only `delete`d, never unregistered, and the map isn't cleared. That can leave libdlt with dangling registrations pointing at freed memory.

### Ownership / robustness

Most of the above comes back to the map being `unordered_map` with raw `new`/`delete`. Switching the value to `unique_ptr` and giving the json decoder an RAII guard would make the leaks and the manual cleanup loop go away on their own. Related: in the parse loop, `new DltContext` then `emplace(...)` leaks the context if `emplace` throws.

One more: `start_qnx_slogger2` grabs the thread stack with `malloc(PTHREAD_STACK_4K * 4)` and aligns it by hand (there's even a comment proving the result stays in bounds). `posix_memalign` or just `pthread_attr_setstacksize` would drop all of that.

### Minor

Diagnostics are mixed. Setup and error paths use `printf`/`fprintf(stderr)` while the rest of the file goes through `DLT_LOG`, and on a QNX target the stderr ones may not show up. There's also the usual const-correctness and C-style cast cleanup, plus `MALLOC_ASSERT` in the header doesn't parenthesize its argument (`if(x == NULL)`), which breaks for non-trivial expressions.

### Note + question

Docs mention a single-threaded redesign of `dlt-qnx-system` since 2.18.10, but the adapter on `master` still has the separate `slogger2_thread` and the manual stack setup, so if a rewrite is already in progress somewhere, I'd rather coordinate than duplicate it.

Otherwise I'd like to clean this up around RAII ownership, fix the parse-loop and cleanup logic, and simplify the stack handling. Would you prefer I keep it to the clear bugs first, or take the broader refactor? And is there history behind the current design I should be aware of before touching it? Happy to do it as small compilable commits per the contribution guide.

Read src/dlt-qnx-system/dlt-qnx-slogger2-adapter.cpp and dlt-qnx-system.h, starting with dlt_context_map_read, wait_for_buffer_space, clean_qnx_slogger2, and start_qnx_slogger2. Confirm the desired scope with maintainers, then verify that decoder and context ownership, malformed-entry handling, zero-size handling, registration cleanup, diagnostics, and stack setup are robust without duplicating any redesign already in progress.

Written by the indexing model from the issue text.