gh-154859: Keep the iconv shift state across incremental decode calls

[fedonman]

The iconv codecs opened a fresh conversion on every call, so decoding a stateful encoding in
chunks lost the shift state and silently returned wrong text:

one-shot:    ABC中文DEF
incremental: ABCVPNDDEF

_codecs.IconvDecoder(encoding) holds one conversion that the incremental decoder and the
stream reader keep, so one conversion spans the stream. reset() starts a new one. The
conversion is closed when the decoder is collected.

Only decoding is affected. Incremental encoding re-emits the escape sequences per chunk,
which is more verbose than the one-shot output but decodes back to the same text.

iconv_decode() keeps its original signature. The first version of this passed an opaque
capsule to it alongside the encoding, and the two could disagree: it used the capsule's
encoding and ignored the argument. A type that owns both cannot get that wrong. Thanks
@serhiy-storchaka for the suggestion.

The tests use fixed bytes rather than encoding with the platform iconv, which provides
ISO-2022-CN on macOS and iOS but cannot encode the sample. They skip if the platform cannot
decode those bytes either, and they fail without the change. Note that
encodings._iconv_codecs is frozen, so a rebuild is needed to see that.

Checked with 50k decoders and 20k incremental decoders for a leaked conversion: no RSS
growth. test_import, test_embed and test_interpreters pass, since _codecs now has
module state. This build has no --with-pydebug, so I could not run -R 3:3.

The iconv codecs are new in 3.16, so there is no NEWS entry.

[BHUVANSH855]

These regression tests currently construct the test input with:

data = codecs.encode(text, 'iconv:' + enc)

From the iOS CI failures, it looks like iconv:ISO-2022-CN is available but cannot encode the sample text on that platform, so codecs.encode() raises UnicodeEncodeError before the incremental decoding path is exercised.

Would it make sense to either skip the test when the sample text cannot be encoded on the current platform, or make the test independent of platform-specific iconv encoding support (for example by using precomputed encoded bytes)?

[serhiy-storchaka]

I wonder if implementing a simple type with the decode() method that holds the encoding and the state would be simpler.

[fedonman]

@BHUVANSH855 You were right, and it failed on macOS too, not just iOS. The tests now use fixed bytes instead of encoding with the platform iconv, and they skip if the platform cannot decode them.

@serhiy-storchaka Done, thanks. _codecs.IconvDecoder now holds the encoding and the conversion. It also fixed another issue: the capsule was passed next to an encoding argument that iconv_decode() then ignored, so the two could disagree. iconv_decode() keeps its original signature now.