The Conditions system was designed with the intent that conditions could

be dynamically registered and unregistered as needed, offering

extensibility in the types of condition choices presented and processed.
This was never tested until now, and we've found a few flaws. One of

those is that ConditionField was calculating the valid choices at

field definition time, and held on to that when copying for a new form

instance. The choices present initially would remain present, and we'd

never recalculate.
To work around this, we now defer any processing of choices until we

need them, and we always refer back to the ConditionSet provided at

the latest initialization time (such as when initializing fields for a

form instance).
We remember the initial choices provided to the field and to the widget,

and refer back to that whenever we need to start fresh. If this is a

class, it's instantiated as late as possible. Same if it's a callback

providing an instance. This state is never deep-copied over to a new

field, allowing new instances to reflect the available choices at that

moment in time.
ConditionsWidget is now the source of truth for the condition choices.

ConditionsField has a wrapper that forwards on to that one. This

simplifies lifecycles considerably.
To take full advantage of this, callers should pass in an instance and

not a class when caling the field.
There's also one fix in here for managing widgets. We were accessing

the value field's widget attribute, which didn't exist. Initially,

this code was built to work with form fields, but we moved to a wrapper

class. We now define a forwarding attribute to get the inner field's

widget.

Unit tests pass.
Tested this with other in-progress work for more dynamic condition

choices. Verified that I could enable an extension and see all the

choices.