Stalled custom field development

[Max Kanat-Alexander]

	Thinking about it even more, here's what we'd want to do:

	(1) Add infrastructure necessary to "genericize" some of the current
fields. I'll have to do some of this anyway for Generic Field Watching.
We could start with rep_platform -- that'd probably be the easiest one,
since it's not even used by all installations.

	(2) Move that one field into that generic framework, with the
associated changes to the backend, with no changes to the UI.

	(3) Move the other enum fields into that generic framework, except
status and resolution (which probably still need to be separate at this
stage).

	(4) Add a framework to add similar fields.

	(5) Add a UI to add those fields.

	(6) Add other features (see comment 239 on the custom fields bug for
what "other features" would be).

	This is probably the best way to go from what we have now in Bugzilla
to custom fields. Step 1 could probably also be broken down a lot. I
picture a Bugzilla::Field module and a lot of subclasses.

	I'd imagine that a structure similar to what we used for userprefs
would work for a lot of that. In this case, that means FAD.

	I think that Dave is thinking about the schema stuff as we speak, by
the way, FWIW.

	-Max