Add direct type parsing that bypasses string allocation

[jimhester]

Summary

• Implements direct buffer access for numeric parsing, avoiding intermediate vroom::string allocation
• Adds field_span struct to represent byte ranges in the source buffer
• Updates vroom_dbl and vroom_int to use direct parsing when available
• Falls back to string-based parsing for multi-file collections or connections

Changes

• Add field_span struct in vroom.h representing byte boundaries for a field
• Add get_field_span() and get_buffer() methods to index interface
• Implement these methods in delimited_index, fixed_width_index, and index_collection
• Add parse_value_direct() template in vroom_vec.h for direct buffer parsing
• Update vroom_dbl and vroom_int collectors to use direct parsing when buffer is available
• Store index pointer in vroom_vec_info to enable buffer access

Test plan

• All existing tests pass (1163 passed, 4 skipped)
• Direct parsing path is enabled when single file is read from memory-mapped source
• Fallback path works when buffer is not available (connections, multi-file)

Closes #1

[jennybc]

Closing an O.G. issue!

[jimhester]

CC got a little over eager about which repo it was supposed to be opening the PR in, this can probably be ignored for now. If this experiment works out I will have some bigger PRs in the hopefully near future :)

[jennybc]

Yeah I noticed you working in the repo previously known as simdcsv, which is mentioned in the maintenance notes here.

I have returned to some vroom work after a period of relative neglect. So it might be good to chat soon, just so I know the shape of what might be coming in these bigger PRs.

In fact, I could probably just use a good consult re: vroom and readr design and history, now that I've grown more active on it again. For example, I'm seriously considering inlining vroom into readr (i.e. all of the compiled code, in particular) and putting vroom as a standalone package into some sort of frozen/bare minimum maintenance state (with an eventual plan of archival). I have many reasons for this, which I'd be happy to discuss and kick around with you.