stop carrying groups and tags properties that API3 loads

Port to 5.0.x of #3628599 (closed) !52 (merged)

Leaves group and tag out of the return list in CiviEntityStorage::loadFromCivicrm(). API3 lists them with Contact's read fields, but they are Contact.get filters. Returning them adds civicrm_group_contact, civicrm_group_contact_cache, civicrm_entity_tag and civicrm_tag to the query for every contact loaded. Contact is the only entity type that has them.

How each mode handles them before this change:

• api3 asks for them, as 4.0.x does. Upgraded sites run in this mode, and it is the one this MR changes.
• auto also asks for them, because its metadata comes from API3. Contact reads go through API4, which ignores the unknown names, so they cost nothing there.
• api4_native never asks for them. API4's groups is a Filter field, which the metadata normalizer drops. API4's tags has a different name and is unaffected. On CiviCRM 6.22 it is a writable field and stays a base field.

Behaviour change

Neither was ever a field. But API3 returns them as groups (comma-separated group IDs) and tags (comma-separated tag names), and Drupal core's initFieldValues() keeps keys that aren't fields as plain values on the entity. So in api3 mode a loaded contact has had $contact->groups and $contact->tags, which PHP and Twig can read. CiviCRM Entity never reads them. After this change they are NULL in api3 mode too, as they already are in auto and api4_native.