Rewrite container parsing

[yaito3014]

partially addresses #25
supersedes and closes #50

including:

• Rename is_substitute to can_hold
• Rewrite parse_into_container with constexpr if
• Remove raw, _where and subrange-related stuff from the entire codebase
• Fix the arbitrary leftover being wrongly preserved on the partial success of the underlying sequence parsers

Todo

• Revert back the commented out tests
• Fix typo pass_attibute_as_is -> pass_attribute_as_is
• Rename build_container to default_container
• Remove the branch fix-swapped-template-argument
• Remove raw directive
• Remove unused_container and assume_container if possible After some investigation, I think it's impossible
• Move can_hold to core I think this can be placed under traits
• Add tests
  • Some test to-dos have been moved to Eliminate single element tuple-like from user-facing API #42

---

Removal of the raw directive

What raw does

The raw directive wraps an inner parser and produces the iterator range (begin/end pair) of the successfully matched input as its attribute, instead of the semantic value that the inner parser would normally yield.

Use cases

A typical use case is extracting the raw matched substring from the input. For example, while int_ produces an int as its attribute, raw[int_] produces the iterator pair corresponding to the matched portion of the input. This can be useful for retaining the original string representation of parsed content or recording source positions for error reporting.

The problem

Internally, the library needs to determine whether a parser's attribute is compatible with container types (e.g., std::vector) when resolving exposed attributes. With raw in the picture, the attribute type becomes an iterator pair, which means the iterator type must be known to perform this compatibility check accurately.

However, the iterator type depends on the input source and is not available at parser definition time. This fundamentally conflicts with the design goal of determining attribute compatibility statically from the parser definition alone. Supporting raw correctly would require propagating the iterator type as a template parameter throughout the attribute compatibility logic, significantly complicating the library's internals.

Rationale for removal

The use cases for raw are relatively niche, and most of them can be addressed by creating a custom parser class that deals with the actual iterator and sentinel positions directly. Note that _where, which is already deprecated in favor of raw, should also be fully removed as part of this change. Given the disproportionate complexity raw introduces into the type system, its removal is a reasonable trade-off in favor of a cleaner and more consistent internal design.

[saki7]

𝑺𝒖𝒑𝒆𝒓 𝑻𝒉𝒂𝒏𝒌𝒔