Data loss under certain (rare) conditions

While working on the D6 port, I discovered a critical bug in CCK's field data storage.
When editing a field's settings, there are some boundary cases which can result in the loss of the data stored in the field for all nodes.

Specifically, this happens when a field update involves both changing the 'multiple' status *and* a field setting that changes the collection of db columns used to store the data.
Typical case is changing a (non-shared) text field from 'single' to 'multiple' *and* from 'filtered text' to 'plain'.
Fortunately, you don't get to do that everday. Besides this bug is probably here since the very early CCK 4.7 releases, and has never been reported AFAICT.

Only the field types whose set of columns depends on the fields settings are affected. To my knowledge, that's only :
- 'core CCK' text fields
- contrib Date.module date fields
but I'm not familiar with *all* contrib CCK fields available out there.

Attached patch should fix that, but since it affects the most critical part of CCK (data storage), we need to fully and extensively test this before committing (even to a -dev release).

I already tested the patch with text fields. Additional help welcome (esp. contrib field developpers) :
- Please report any contrib field modules that could be affected.
This means : a field module for which the set of columns returned by hook_field_settings($op = 'database columns') depends on something the site admin can change on the field edit form.
- For those field types only (no need to test nodereference or imagefields), mess up with the field's settings in all possible ways you can think of :-) :
use a field that is not shared across multiple content types
change the field from single to multiple values (or back) *and* some of the relevant field settings
check that you don't get any SQL errors, and that your nodes still contain the right data for the field
use a test site, obviously :-)