plistlib leaks ExpatError/LookupError instead of InvalidFileException for malformed XML

Bug description:

plistlib.load()/loads() is documented to raise plistlib.InvalidFileException when a file cannot be parsed:

The parser raises InvalidFileException when the file cannot be parsed.

For the XML format, _PlistParser.parse() calls expat's ParserCreate().ParseFile() with no exception translation at all. Two classes of malformed input escape as the underlying exception instead, and neither is a ValueError (InvalidFileException's base class), so code that follows the documented contract and catches InvalidFileException (or even just ValueError) does not catch these:

1. XML that is not well-formed raises a raw xml.parsers.expat.ExpatError.
2. An <?xml ... ?> declaration naming an encoding Python's codec registry doesn't know raises a raw LookupError. This is what CIFuzz found in gh-152211 (LookupError: unknown encoding: Latin-5_________________________); the well-formedness case above is a second, broader instance of the same missing-translation bug.

>>> import plistlib
>>> plistlib.loads(b"<plist><foo></bar></plist>")
Traceback (most recent call last):
  ...
xml.parsers.expat.ExpatError: mismatched tag: line 1, column 14
>>> plistlib.loads(b'<?xml version="1.0" encoding="BogusEncoding"?><plist></plist>')
Traceback (most recent call last):
  ...
LookupError: unknown encoding: BogusEncoding

Expected in both cases: plistlib.InvalidFileException, as already happens for other malformed inputs (e.g. plistlib.loads(b"not a plist") correctly raises InvalidFileException).

Related: gh-152211 (the CIFuzz report for the LookupError case specifically; discussion there is about the fuzz-target/CI setup, not a fix to plistlib itself).

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

• gh-155398
• gh-156177

從 plistlib._PlistParser.parse 開始，該方法由 plistlib.load() 和 loads() 呼叫，並載入 issue 中的兩個格式錯誤 XML 範例。確認格式錯誤的 XML 和未知編碼會被轉換為 plistlib.InvalidFileException，然後驗證現有的格式錯誤輸入行為仍維持不變。