[cpyrt] Parse buffer formats properly instead of character search

[guitargeek]

numpy and other buffer producers canonicalize the PEP 3118 format char of 64-bit integer dtypes (e.g. int64 is always reported as 'l' on 64-bit platforms), but C++ parameters declared as int64_t resolve to 'long long' on macOS and 'long' on Linux. The exact format-char matching in the array converters therefore rejected valid buffers when the resolved type and the canonicalized buffer format differed, breaking e.g. passing numpy int64 arrays to 'const int64_t*' parameters on macOS.

Replace the ad-hoc buffer-format matching with a small PEP 3118 parser in Utility::BufferFormatCompatible(). Formats are reduced to their element type (skipping byte-order prefixes like ctypes' '<q', repeat counts, and the 'Z' complex marker), classified by kind (signed/unsigned integer, float, complex, ...) and native size, and accepted when both match the requested type code. Use it where buffer formats are matched: Utility::GetBuffer() (standard buffer protocol), CArraySetArg() (low-level views), the 1- and 2-dimensional branches of the array converter, and StdSpanConverter (std::span parameters).

This subsumes all previously scattered special cases:

• int/long equivalence on Windows and 32-bit Linux in GetBuffer()
• long/long long interchange for numpy's canonicalized int64 format
• 'z'/'Zf' complex-float naming
• signed char ('b') as bool, kept as an explicit documented quirk

As side effects, ctypes' explicitly-endian '<q'/'<d' buffers are now accepted natively, and complex buffers no longer leak into float parameters through the 'Zd'-contains-'d' substring accident (std::span, which performs no item-size check, previously read complex128 buffers as double).

[aaronj0]

LGTM! This is a nice improvement over the previous heuristic approach and now supports all formats under the PEP 3118 as shown in the test. Can you fix the merge conflicts?

[guitargeek]

Merge conflicts fixed! Could you re-review?