Resolution for custom field types.

Applications can extend the built-in question types with their own, declared as a map of type name to the Ecto type the field casts as — globally:

config :dynamic_form,
  custom_field_types: %{
    "multiselect" => {:array, :string},
    "select_with_search" => :string
  }

or per form (per-form entries merge over — and win against — the config):

<DynamicForm.form
  id="signup"
  custom_field_types={%{"multiselect" => {:array, :string}}}
>

The map does triple duty:

• its keys are the vocabulary — <:field type="multiselect"> (or "type": "multiselect" in data mode) is accepted anywhere a built-in type is; question types in neither the built-ins nor the map are skipped by the renderer (nothing renders — obvious in testing, not broken-looking in production)

• its values drive casting — the changeset casts the field as the declared Ecto type, and {:array, _} types get the same hidden-input normalization as the built-in checkbox/tagbox groups, so required works

• rendering dispatches to the components module — define a matching input/1 clause (see DynamicForm.Components):

  def input(%{type: "multiselect"} = assigns) do
    ~H"""
    ...
    """
  end

Validation beyond casting and required is the application's job — use the validators attribute or the on_change/on_submit lifecycle callbacks.

Custom type names may not collide with built-in question or element types; collisions and malformed maps raise.