Detect refunds that have already been performed

[waiting-for-dev]

On #180, we're handling the charge.refunded webhook event to generate a Spree::Refund copy. However, we're not checking whether the incoming webhook has already been processed in the past.

Although we're skipping the processing when the associated payment has already been fully refunded, it might be the case that we handle twice a partial amount refund. As noted in a comment from the referenced issue, we can't use the transaction ARN as that's something not always available at the moment the event is created.

There're two ways to handle that:

• Generally, through Be resilient against duplicated webhook events #188, making the system resilient against duplicated webhook events.
• Specifically, as another layer of security, associating every created refund with the charge id in another database table.

Another scenario for a duplicated refund would be one that has been initiated by Solidus, calling the Stripe API and getting the corresponding webhook event.

[kennyadsl]

We can probably explore saving the id of the Stripe refund on the Solidus Refund in the transaction_id field. When the webhook comes, we could check if there's an existing refund and skip creating it on our end if so.

[waiting-for-dev]

That could work. We'd need to save it both when we create a refund from Solidus admin and when we create it from an incoming webhook.