fallback: leave the object unread when a header type does not match

[Shaisolaris]

In the pure Python Unpacker, read_array_header() and read_map_header() consume the next object before raising ValueError when it is not an array or map. The C extension leaves it in place, so code that catches the error and then calls unpack() behaves differently depending on which implementation is loaded:

from msgpack.fallback import Unpacker
from msgpack import packb

u = Unpacker()
u.feed(packb(1) + packb(2))
try:
    u.read_array_header()
except ValueError:
    pass
u.unpack()  # fallback: 2 (1 is lost), C extension: 1

For a str, bin or ext the payload is skipped as well. For a map passed to read_array_header(), only the map header is consumed, so the next unpack() returns the first key and the stream is out of step from then on. tell() still reports the old offset, so it also disagrees with what was consumed.

The fix rolls _buff_i back to the buffer checkpoint (the start of the object) before raising, which is the same rollback _reserve() already does for OutOfData in feed mode. The header readers are only called at the top level, so the checkpoint is always the start of the object.

Tests:

• Added test_incorrect_type_does_not_consume_object to test/test_read_size.py, which covers feed and file-like input. It fails with MSGPACK_PUREPYTHON=1 before the change and passes after. It passes with the C extension both before and after.
• Full test/ with MSGPACK_PUREPYTHON=1: 141 passed, 4 skipped. With the C extension: 144 passed, 1 skipped (Linux, CPython 3.12).
• Also checked locally with a script, not added to the PR: it compares the C and fallback Unpackers on 20,000 random sequences of unpack/skip/read_array_header/read_map_header calls over feed and file input with several read_size values. 15,980 sequences differed before the change and 0 after.
• I did not test on PyPy.

[methane]

@codex review please.