Preserve explicit 64-bit suffixes when parsing nondecimal integers

[fhgffy]

Summary

An explicit L or LL suffix should preserve a nondecimal value as a 64-bit integer. Currently, v = 0xffffffffL; parses successfully as an INT64 setting but stores -1 instead of 4294967295. Binary and octal equivalents have the same problem; 0x80000000LL becomes -2147483648.

libconfig_parse_integer applies 32-bit signed interpretation before inspecting the suffix. Skip that narrowing step when the parsed number has an L suffix, then let the existing suffix handling select the 64-bit type. Unsuffixed signed interpretation, decimal parsing, and malformed-input/overflow checks are unchanged.

The regression covers all three nondecimal bases, both suffixes, the signed-32-bit boundary, values around the unsigned-32-bit upper boundary, INT64_MAX, decimal controls, unsuffixed compatibility, and exact serialized output. This is separate from the integer-assignment conversion change in #302.

Validation

Tested on Linux x86_64 with GCC/G++ 14.2.0, CMake 3.31.6 and Ninja 1.11.1, based on 1e2dedd046f5119e67b0ccbda5916e8aff55c142:

• Clean baseline: all 17 native tests pass
• New regression on the unchanged implementation: fails on the incorrect negative value
• Patched implementation: all 18 native tests pass; C/C++ libraries and examples build
• ASan/UBSan: all 18 tests pass with ASAN_OPTIONS=detect_leaks=0; LeakSanitizer was not run
• Additional local probes: C++ public reads, nested containers, malformed/range rejection, and setter-write-parse round trips
• Additional local matrix: fresh build and 18 tests pass; 600 typed parses, 594 round trips, and 17 rejection cases pass
• git diff --check passes

The additional matrix excluded six unsuffixed negative binary round trips after reproducing a separate existing binary-writer failure on the unchanged base. Their parsing checks passed; this patch does not change that writer behavior. Existing octal-to-decimal serialization is also unchanged.

Windows/MSVC, macOS, 32-bit targets, alternate C libraries, embedded hardware, fuzzing and Autotools were not tested locally. Autotools tools are unavailable in this environment. These results do not establish LeakSanitizer or cross-platform coverage.