CustomFields - Improve metadata about which custom groups belong to which entities

[colemanw]

Overview

This makes the relationship between Custom Field Groups, entity types and subtypes discoverable via APIv4 metadata. This paves the way for Afform and SearchKit to handle custom fields intelligently, and for extensions to easily provide new types of entities with complex custom data mapping.

Before

Metadata did not exist. Custom field groups to load for each entity type was hard-coded on forms and templates throughout CiviCRM. Generic handling was not possible.

After

Metadata-driven tools like Afform and SearchKit will be able to gather custom fields for entity types and sub-types via the API.
Virtual entities with sub-types (like ECK) can easily extend the mapping.
Unit tests added.

Technical Details

In addition to adding metadata, this PR resolves a few oddities:

• Custom field support for Grant entities was still hard-coded in core even though CiviGrant has been moved to an extension. I switched it to use the cg_extend_objects optionGroup and removed the Grant hard-coding from core.
• There was general confusion about whether sub-type pseudo-values (e.g. ParticipantEventName, ParticipantStatus) were allowed in the CustomGroup.extends column or if they were only for presentation on the custom group quickform. I investigated and it turns out to be the latter. APIv3 CustomGroup.create has some special logic to transform e.g. extends: 'ParticipantEventName' into extends: 'Participant' with the appropriate value for extends_entity_column_id. I kept that around but removed unreachable code for handling those pseudo-values being stored in the extends column.
• There was a very odd use of the OptionValue.description column by CiviCase, where it was actually storing the name of a callable function to return the list of case types. That's problematic for several reasons, not the least of which is that description is a localized field so the whole thing would break in multilingual mode! I switched over to a "grouping" value of case_type_id and taught the code to just call getFields on that field name.
• APIv3 was having trouble handling custom data for entities with odd names (like PCP) or recently-renamed BAOs (like DedupeRule). I improved the APIv3 entity-to-name mapping to solve this.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[colemanw]

PR review note: in addition to new tests added in this PR, this functionality is massively covered by existing tests, notably the APIv3 syntaxConformanceTest which checks every entity for custom fields. Lots of other APIv4 and APIv3 tests cover custom data as well.

[eileenmcnaughton]

I gave this an r-run by creating custom fields for some of the more obscure types - grant, survey, participant-event and was able to create the fields & edit and save the values.

I'm OK with merging this but I just want to be sure that some thought has gone into the cleanup on the Grant mgd option value - since we seem to have had no-end of issues around grant mgd option values - I guess unlike the others this one is all new?

[eileenmcnaughton]

@colemanw I'm going to merge this since I don't think my question above is blocking & I know you have targetted the upgrade scripts at 5.49 - if necessary we can fix as a follow up. @demeritcowboy might have thoughts on it too

[colemanw]

Thanks @eileenmcnaughton. I believe we've got all the kinks worked out for those managed entities at this point. Should be smooth on upgrades and new installs alike, as in both cases this will be inserting a new option value.