Asset cache is not invalidated after group membership log status changes

The asset's cache needs to be invalidated after a log's status that assigns a group membership is changed (done/pending).

Solved by implementing a LogEventSubscriber like we have done in farm_location for invalidating asset cache with movement logs.

related: asset in group's location (in Views) doesn't update when asset's group location changes

Solved by invalidating group members' cache tags when the group's location changes.

This is a little bit tricky since we start to depend on (and duplicate) the farm_location LogEventSubscriber::invalidateAssetCacheOnMovement logic to determine if a movement log has been updated. To simply things a bit I created a new public static function: public static function isActiveMovementLog(LogInterface $log): bool that the farm_group log event subscriber can use.

Alternatively, *I think* we could include this isActiveMovementLog function on the log.location service itself. That would make the logic even more reusable.

Test and implement.

Rather than test this behavior by making JSONAPI requests I created a new FarmEntityCacheTestTrait test trait that provides a couple helper methods for testing invalidation of entity cache tags directly.

At first I thought I could use the entity cache bin to check for cache hits/miss in tests:

\Drupal::cache('entity')->get('values:asset:1');

But when I tried this I was *always* getting a "cache hit". I saw that these cache entries have a different cache tag (asset_values) in the DB so I think they are used for something else (lower level) than we need.

I settled on simply creating a new cache entry in the default cache bin that is dependent on the entity's cache tags. This is more similar to how the drupal render cache works anyways, each entry is dependent on other cache tag(s):

 \Drupal::cache()->set('farm_entity_cache_test:asset:1', 'data', Cache::PERMANENT, $entity->getCacheTags());

I refactored the existing farm_location tests to use this approach for testing cache tag invalidations.

This has led me to discover another more general bug re: caching... logs that are "done" with a timestamp in the future add another level of complication here. This is especially important for requests via the API. Consider the following:

1. Create an asset.
2. Create a movement log in the future (5 minutes) with the status set as "done".
3. View the asset's JSONAPI resource (this will cache the asset's resource in the jsonapi_normalization cache bin)
4. Come back in 5 minutes and load the JSONAPI resource. Unchanged.
5. Go to the log edit page and re-save it without making changes. JSONAPI resource is updated.

Not sure how important this is. It seems like it *could be* semi-straightforward to support this... Drupal has the concept of cache tags and the cache "max-age". *In theory*, when a planned log is created, we could set the asset's cache max-age to be the timestamp of that log. That way anything cached from the asset (and respecting its max-age) would be rebuilt appropriately. Of course, I'm not sure if we're able to specify an individual asset's cache max age... gotta sign off. This would probably be best to tackle in a separate issue.

Just tacking on a couple commits to more accurately reflect what the LogEventSubscribers are doing.