Consider splitting into envision (core) and envision-components crates

[ryanoneill]

Context

From user feedback: the crate is 66k+ LOC with the full component library. Feature flags help, but pure-framework users who only want the core TEA architecture (Component trait, Runtime, Command, etc.) carry the weight of 30+ components they may not use.

Proposal

Evaluate splitting the crate into:

• envision — core framework (Component trait, Runtime, Command, Event, Theme, Layout, etc.)
• envision-components — the component library (all 30+ components), depends on envision

Considerations

• Feature flags are the current mitigation and work well for now
• A crate split is a larger architectural change that should be planned carefully
• Need to evaluate: compile time impact, API ergonomics, re-export strategy
• The component library should remain a first-class citizen, not an afterthought
• Consider whether a workspace structure makes sense

Acceptance Criteria

• Evaluate compile time with and without components
• Design crate boundary (what goes where)
• Prototype workspace structure
• Ensure envision re-exports components for backwards compatibility
• Migration guide for existing users

Priority

Post-0.5.0. Feature flags are sufficient for now.