Release v2.9.0

Added

• AutoCommandForm - generates a CommandForm's field list from the command's own propertyDescriptors instead of writing one field per property by hand, choosing each field's component by property type through a FieldTypeProvider registry. Built-in providers cover string, number, boolean and Date.
• registerFieldTypeProvider - registers a provider for any other property type (a Cratis concept, an enum, a custom value object). Most-recently-registered wins, so a provider registered by consuming application code overrides one of the built-in defaults.
• exclude prop on AutoCommandForm to leave specific properties out of the generated field list.
• New AutoCommandForm documentation page and a Storybook story.

(#104)

Notes for reviewers

The issue frames this as "built on top of a provider model in Arc," but the provider registry lives entirely in this repo instead. Arc.React has no knowledge of Components' concrete PrimeReact-based field implementations (InputTextField, NumberField, ...) and doesn't need any - Command.propertyDescriptors already exposes everything AutoCommandForm needs, with no Arc changes required. Keeping the type-to-component mapping where the component implementations actually live avoids Arc.React taking on a dependency direction back toward Components.

AutoCommandForm computes its field list itself and passes the resulting elements as CommandForm's own children (rather than, say, a child component CommandForm discovers on its own) - CommandForm's field detection walks props.children as written, without rendering nested components to see what they produce, so the generated fields have to already be real children by the time CommandForm processes them. This was confirmed by reading CommandForm.tsx's getCommandFormFields before committing to the design, rather than assumed.