APIv4 Entity.get refactor to be more efficient

[colemanw]

Overview

Makes APIv4 Entity.get more efficient.

Technical Details

APIv4 Entity.get no longer does a file scan when getting one or more entities by name.
Also deprecates the includeCustom param which was redundant with the where clause.
This is the first APIv4 param to be deprecated - added handling to emit a warning when using a deprecated param and hide deprecated params in the APIv4 explorer.

Comments

This PR doesn't go as far as to add caching because there wasn't consensus that it would actually help.

[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]

@totten this uses the "metadata" cache which by default has a SQL backend. I'm honestly not sure if the SQL query is any better than the filescan. Kinda pointless if not.

[totten]

Not really sure... Some guesspinions for different use-cases:

• If we're talking about a personal dev-box with one site and huge RAM/CPU resources, then there's probably no difference.
• If we're talking about shared/cloud hardware and a web-domain that gets sporadic usage, then an intermittent call to civicrm/ajax/api4/Entity/get is probably better if it's served from SQL-cache rather than filescan.
• If we're talking about a background PHP script that says for ($i=0; $i<100; $i++) { civicrm_api4('Entity','get'); }... then maybe iteration $i=0 is a wash, but iterations $i=1...100 benefit from SqlGroups in-memory frontcache.

[colemanw]

Ok I took out the caching commit, now this PR should be uncontroversial and an easy merge.

[seamuslee001]

This looks fine to me