Fixed vs. variable field settings

Originally (like a year ago), "field settings" were those things which affected schema and could not be changed except by a mythical "field conversion" system and "instance settings" were the lightweight things that could be changed at any time.

Later, we realized that some things should be field settings so they are inherited by all field instances even though they do not actually affect the schema. "Allowed values" for a list field is the standard example.

While discussing taxonomy as a field at the DCDC code sprint, we realized that even though changing some field settings would not affect the schema, they would still constitute an expensive operation. For example, suppose a list field changes its "allowed values" by removing some of the allowed keys. The site may already have data items for that field in the database that use the removed keys and are thus no longer valid (they would not pass field validation). In the taxonomy case, if a taxonomy field indicates which vocabs are allowed, and that changes, existing data items may then contain terms from a vocab that is no longer valid for that field.

This leads to a situation in which we need:

1. Field settings that cannot be changed except by a field conversion process. These include schema settings and anything that affects what constitutes valid data for the field.

2. Field settings that can be changed. Given the "valid data" constraint, are there remaining known use cases for this?

3. Instance settings that can be changed, like "required" and "weight."

If the Field API is going to support 1 and 2, then it also needs to provide some way to differentiate between them so the UI knows what to display on a field edit form.