For Operaton Remote implement outbox pattern for external task completion

> Adapted from https://github.com/bpm-crafters/process-engine-adapters-camunda-7/issues/121

### Scenario

* Library version: latest
* Description of your use case: In order to improve the confidence in the TX implementation of the used client, we want to make sure the Operaton adapter can use an outbox-pattern approach to complete external tasks. Because Operaton (like Camunda 7) uses an external-task lock/complete protocol over a remote REST API, the same distributed-transaction problem applies here. More details on the underlying problem: https://medium.com/miragon/leveling-up-mastering-the-distributed-transaction-problem-in-zeebe-d4bbbca295d6

### Current Behaviour

Direct "TX after-commit" completion is used: the external task is completed against the Operaton engine only after the local business transaction commits. If the call to Operaton fails after the commit, the completion is lost and the task will be re-fetched, potentially re-executing business logic without idempotency guarantees.

### Wanted Behaviour

An outbox-pattern implementation for external-task completion in the Operaton Remote adapter, based on Spring Data JPA (as one of the options).

A **passive outbox** would already be sufficient for many use cases and could be decoupled from the business code via an interface:

* When an external task completes, the adapter saves the completion payload (variable map) **within the still-running business transaction** (if any).
* If the subsequent call to Operaton fails (for whatever reason), nothing is lost.
* When the external task is fetched and locked again, the adapter looks for a previously stored completion and, if one exists, reuses the completion payload and sends it to Operaton again, completing the task so the process can continue.

The business code could optionally implement the interface, configure the adapter to use the implementation, and take care of persisting/loading completion payloads in its own database and structure. When configured, the adapter would guarantee idempotency by reusing previous results and effectively piggyback external-task executions to complete tasks based on earlier executions.

### Possible Workarounds

Manual implementation in every project.

Start with the external-task lock/complete flow in the Operaton Remote adapter and trace the current TX after-commit completion. Compare it with the requested passive outbox behavior and Spring Data JPA option; done means completion payloads are stored in the business transaction, reused after failure, and sent when the task is locked again.

Written by the indexing model from the issue text.