Stop incremental snapshots based on additional condition or ad-hoc signal id [DBZ-6138]

Migrated from [DBZ-6138](https://issues.redhat.com/browse/DBZ-6138)

The current behavior of the {{stop-snapshot}} signal is that:

1. Not specifying {{data-collection}} values stops all incremental snapshots.
2. Specifying a {{data-collection}} value set stops incremental snapshots for those collections.

However, if two incremental snapshots have been submitted for the same collection/table but were specified with different additional conditions, it would be helpful to explicitly pick which of those tuples should be stopped rather than both. If the stop signal could also be supplied with the {{additional-condition}} predicate, we could use this to differentiate between the different incremental snaphots for that collection/table.

Additionally, as we continue working toward integrating new features such as Incremental Snapshots into the Debezium UI, we should also think about whether it makes sense to serialize the signal ID into the {{DataCollection}} tuple; allowing a stop signal to merely specify the original ad-hoc {{exec-snapshot}} signal ID as an alternative. If we were to consider a UI where we have a list of snapshots based on their respective ID, the ID could be used to identify a specific snapshot rather than needing to send a much larger payload to the backend to stop a snapshot.

The payload names no implementation files, entry points, or tests. Start by reviewing the existing stop-snapshot and exec-snapshot signal handling described in the issue; done requires a decided, testable way to target one snapshot by additional condition or signal ID while preserving current all- and collection-based behavior.

Written by the indexing model from the issue text.