ENUMs weren't allowed to have character 0xff, a perfectly good character in many locales.
This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from
being used (because they too would get converted to 0xff on load). Now if 0xff makes an
appearance, we find a character not used in the enum and use that as a separator. If no
such character exists, we throw an error.

Any solution would have broken some sort of existing behaviour. This solution should
serve both fractions (those with 0xff and those with ',' in their enums), but
WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/
That is, mysqldump with their current server, and restore when upgrading to one with
this patch.

(port of the original 4.1 patch. incorporates some suggestions by kaamos.)


mysql-test/r/type_enum.result:
  Bug#24660: "enum" field type definition problem
  
  Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable
  char in some locales), or ',', or both.
mysql-test/t/type_enum.test:
  Bug#24660: "enum" field type definition problem
  
  Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable
  char in some locales), or ',', or both.
sql/table.cc:
  Bug#24660: "enum" field type definition problem
  
  Revert fix for Bug#20922.
sql/unireg.cc:
  Bug#24660: "enum" field type definition problem
  
  Use a field-separator for ENUM-values that is not part of those values. If impossible,
  throw error.