Add input limits to prevent DoS from untrusted version strings

[andrew]

Bounds input length and constraint count at parser entry points so malformed or hostile input fails fast instead of consuming unbounded memory or CPU.

The three caches in Version, Constraint, and Parser use raw input strings as hash keys and evict by entry count, not byte size. An attacker comparing 2000 unique multi-megabyte version strings could pin gigabytes of memory before eviction starts. Version::MAX_LENGTH (256) at construction means oversized input raises before reaching any cache, capping key memory at entries * 256.

parse_constraints runs exclusions.each { |v| range = range.exclude(v) } where each exclude splits an interval and reconstructs the range with sort and merge. Interval count grows from 1 to N over N exclusions, doing O(N² log N) work. Input like vers:npm/!=1|!=2|...|!=5000 ran for several seconds. Parser::MAX_CONSTRAINTS (64) caps the split, and the split itself uses a limit arg so we never materialise thousands of substrings.

Parser::MAX_INPUT_LENGTH (2048) at parse and parse_native bounds total string work before any regex or split runs.

The bare rescue in the maven union parser now catches only ArgumentError, letting Interrupt and NoMemoryError propagate.

Limits sit well above real-world inputs: longest version strings in the wild are Maven snapshots around 60 chars, complex SBOM ranges rarely exceed 20 constraints. Error messages report the offending length but not the string itself to avoid echoing payloads into logs.

test/test_security.rb covers each limit and asserts that inputs near the limits still parse in well under a second.