feat(typed-arrow-dyn): support view and view based projection in typed-arrow-dyn

[ethe]

• Restructured DynCellRef<'a> into a raw-backed handle with documented constructors plus as_* / into_* accessors, enabling zero-cost reborrows of all Arrow primitive and nested types without enum pattern matching.
• Added lifetime-erased raw view structs and conversion helpers, extended DynSchema with iter_views, and moved view validation logic into DynViewError for consistent diagnostics (row/column bounds, schema mismatches, null violations).
• Expanded developer surface: new dyn_views example showcasing projections and nested traversal with the accessor API, and a comprehensive integration test suite (tests/views.rs) covering primitives, nested structs/lists, maps/unions, dictionaries, projections, and deep nesting.

[belveryin]

Question:

Could downstream crates that disable the views feature start failing to compile because we now emit view-related code unconditionally (via if cfg!(feature = "views") at macro-expansion time) instead of leaving #[cfg(feature = "views")] guards in the generated output, meaning their builds would reference ArrowBindingView items that weren’t compiled for them?

And if this does introduce a breaking change for those dependents, do we need to bump the affected crate versions (e.g., typed-arrow and typed-arrow-derive) or otherwise communicate the breakage explicitly in release notes?

[ethe]

This PR does not relate to typed-arrow, it is trying to add view support in typed-arrow-dyn, but I can answer your question here.

Could downstream crates that disable the views feature start failing to compile because we now emit view-related code unconditionally (via if cfg!(feature = "views") at macro-expansion time) instead of leaving #[cfg(feature = "views")] guards in the generated output, meaning their builds would reference ArrowBindingView items that weren’t compiled for them?

I don't think so, only opening view feature gate of typed-arrow-derive will generate #[cfg(feature = "views")] codes. And this feature would be automatically open while user opens the view feature of typed-arrow

And if this does introduce a breaking change for those dependents, do we need to bump the affected crate versions (e.g., typed-arrow and typed-arrow-derive) or otherwise communicate the breakage explicitly in release notes?

No, this PR only changes typed-arrow-dyn crate.

[KafkaCat]

Just curious: does this support projection of nested structs?