The CustomField stuff is built real weird.

As written, the actual classes need to extend application classes (say, DifferentialCustomField) to work. But we don't want to implement DifferentialTextCustomField, ManiphestTextCustomField, DiffusionTextCustomField, etc., for every application to have text fields everywhere, so the "solution" is that fields can "proxy" another field. So a "text" field in Differential is really a DifferentialCustomField proxying a PhabricatorStandardTextCustomField or whatever. This gives it both "Differential" behavior and "Text" behavior.

This is pretty gross and weird, and we don't do it anywhere else. CustomField generally got a lot of things mostly-reasonable but has a few things which just didn't turn out that well. Later abstractions like EditEngine + EditField feel far better factored. I've moved us a bit away from as heavy an investment in CustomField to some degree in changes like T11114, and imagine it will eventually be wrangled into something a little more modern/sensible (notably, without all the proxying stuff).

For now, the proxy stuff is all just saying "if this is proxying something, the default behavior is whatever the thing we're proxying is doing; otherwise it's return null". This is a little like a really hacky, cumbersome sort of multiple inheritance? Hopefully we'll be able to get rid of it eventually, maybe when something like T418 motivates more extensive work on CustomField.