Stronger typing for AsIR composition

[Shfty]

• Currently, Modify, Combine, etc. don't make any checks against the AsIR implementors they compose
• As a result, there's nothing to prevent a user from using Circle as a Modifier or Combinator, or a Modifier or Combinator as a field
• Two major facets:
  • Categorization for Field, Input Modifier, Output Modifier, Combinator
  • Should be enough to solve the problem at a basic level
  • Implement each as an opt-in subtrait of AsIR, use inside Box dyn to specify which should be supplied
  • Dependency checking
  • Nice to have, but not critical as-is
  • This touches on lifting functions to context I/O, as the current Context -> Context model does not encode any information about types that are read or written
  • Would require codifying inputs and outputs as AsIR member functions
    • Could also use to further generalize FunctionDefinition generation

[Shfty]

Now Shape has replaced DynAsIR, Modify has been refactored to take PreModifier and PostModifier types alongside a DynShape, thus strengthening it against accidental misuse.

The few cases where an arbitrary field was being used as a modifier have been refactored to use a new Prepass wrapper.

Need to do similar for Combine, but that's blocked on #115 due to AsIR not being blanket-implementable from elysian-shapes.

[Shfty]

(Closed unintentionally.)

Also worth considering a new abstraction over single-field wrappers, as many existing Shape implementors follow the pattern of composing a DynShape and its hash / domains / functions / structs, then calling its entrypoint from a new CONTEXT -> CONTEXT function.

[Shfty]

Done: Combine now uses the Combinator trait to assert type-level correctness. Will open a separate issue for single-field wrappers.