Return error instead of asserting on CborInvalidType in advance functions

[Eun0us]

Summary

Replace cbor_assert(it->type != CborInvalidType) with an explicit error return
(CborErrorIllegalType) in cbor_value_advance() and cbor_value_advance_fixed().

Problem

When parsing malformed CBOR input, recursive container walking can produce a
CborInvalidType state in the iterator. The current code triggers assert() → abort(),
which is inappropriate for a library that processes untrusted input. Callers have no way
to handle the error gracefully.

Crash output:

fuzz_tinycbor: cborparser.c:508: CborError cbor_value_advance(CborValue *):
  Assertion `it->type != CborInvalidType' failed.
SUMMARY: libFuzzer: deadly signal

Fix

Replace the assertion with an early return of CborErrorIllegalType, allowing callers
to detect and handle invalid CBOR data without crashing. The same pattern is applied
to both cbor_value_advance() and cbor_value_advance_fixed().

Testing

Found by fuzzing with libFuzzer + AddressSanitizer on tinycbor bundled with ESP-IDF v5.3.
The fix eliminates the crash on malformed input while preserving correct behavior on valid CBOR data.

[thiagomacieira]

Sorry, I don't want this. If you don't trust the input you're parsing, you can check whether the decode was successful in your code with cbor_value_is_valid(). If you can trust the input (for example, you've already verified it once and are doing a second pass for some reason), then you don't need to pay the price twice.

Callers have no way to handle the error gracefully.

Unless you can give me an example where this error can happen and there's no way to avoid it in the first place.