fix: trim before parsing numbers

[aryan-212]

Which issue does this PR close?

• Closes arrow-cast numeric parsers fail to parse whitespace-padded strings #9538

Rationale for this change

The Parser::parse implementations for numeric types did not trim whitespace before parsing. This caused values like " 42 " or " 1.5 " to fail parsing and return None, even though they represent valid numbers.

What changes are included in this PR?

• Added .trim() calls before parsing in FloatType Parser implementations.
• Added string.trim() at the top of the parser_primitive! macro, which covers all integer and duration types.

Are these changes tested?

Yes. Added test_parse_trimmed_whitespace covering:

• Float types with leading/trailing spaces and tabs/newlines
• Signed and unsigned integer types with whitespace
• Negative integers with whitespace
• Whitespace-only strings returning None

Are there any user-facing changes?

Yes. Numeric parsing now accepts strings with leading/trailing whitespace. This is a relaxation of the previous behaviour (previously None, now Some(value)), so it is not a breaking change.