docs(mix_generator): record @MixWidget variant constructor decisions

[leoafarias]

Related issue

Closes out the design questions raised in #998 and PR #999. No code changes.

Description

Adds guides/mix-widget-variant-constructors.md, a decision record for how
@MixWidget generates enum variant constructors and why it takes that shape.

The feature itself already ships in mix_generator 2.2.0-beta.2 (added in #968).
Nothing here changes behavior — this captures the reasoning so a future
simplification pass re-derives from the record instead of guessing from the code.

Decisions recorded

The unnamed constructor stays alongside the generated named constructors.
#998 asked for named-only widgets; declined. A variant that comes from state,
config, or a UI control cannot select a constructor at compile time, so
named-only forces those call sites to abandon the generated wrapper and rebuild
the style by hand. Remix measured 16 such sites in their own migration.

No runtime variant API belongs in mix. #999's first implementation added
variantsFromEnum and applyVariant, which made the recipe return a style
carrying every enum value for the widget to narrow down — building N styles per
rebuild and discarding N-1. The parameter form already builds exactly one, and
gets compile-time exhaustiveness from switch rather than a runtime throw.

The variant enum needs no EnumVariant mixin. On this path the value is only
a switch key inside the recipe and never enters Mix's variant system. Recorded
explicitly, with a do-not-add note, because the rejected design did require it.

Also records rejected alternatives (convention-based enum discovery, a
@MixWidgetVariant marker, per-value constructor selection) with the reason each
was rejected, and the decision to remove factoryParameters and rename
widgetParameters to targetParameters in a follow-up — including the costs
accepted and the one outstanding input.

Review Checklist

• Testing: documentation only; no code paths touched
• Breaking Changes: none
• Documentation Updates: this PR is the documentation
• Website Updates: not required