Add DAO fields to API metadata when the entity type name is known

[jensschuppe]

Follow-up to #125

Since the DAO methods for compiling schema fields are static, but ECK entities rely on the entity type for their metadata (table name, etc.), the CRM_Eck_DAO_Entity::fields() method needs to be called after initialization, and can't be relied upon for further calls for different entity types. #125 makes the method not return anything for uninitialized calls.

This PR uses the Spec Provider to gather DAO fields, as they would otherwise not be part of the entity metadata at all (causing e.g. search displays or even the entire SearchKit admin UI to crash).

@colemanw I had to copy a private method \Civi\Api4\Service\Spec\SpecGatherer::setDynamicFk() to save us from changes to Core. I tried to make this more generic, see civicrm/civicrm-core@master...jensschuppe:civicrm-core:daoSpec - this would have allowed for overridden getSupportedFields() methods in DAO classes that depend on the API entity name, but I'm not sure this would cover all relevant cases. And since DAOs are on their way out of Core anyway, I didn't file a PR to Core. Anyway, I'd still appreciate you reviewing.

[colemanw]

I think this is fine for now. But note that when the conversion in https://lab.civicrm.org/dev/core/-/issues/4999 is complete (and we are close!), then none of this will be needed. There won't be a need for DAO files at all.

[jensschuppe]

Noting that this makes the listings of ECK entities (or any get call without where) now get an implicit filter for fields with default values (i.e. now for the created_date and modified_date fields) in https://github.com/civicrm/civicrm-core/blob/01dd6e55f61dfaa89d371b50a1aa456ead67dc99/Civi/Api4/Generic/AbstractGetAction.php#L42, which obviously doesn't make sense.

That was (accidentally) not a problem before, since the DAO did not return any fields. I guess we'll have to provide our own EckDAOGetAction and override that method.