Configure Event Trigger retry logic based on webhook error code or type.

### Is your proposal related to a problem?

I would love to have the ability to configure different retry logic based on the error code or type of error returned by my webhook. For example, I might want a `500` error to be retried, but maybe there are some legitimate `4xx` errors that I would not want retried. For example, our webhook might have multiple side effects dependent on 3rd party APIs, and if one of them gracefully errors, we don't want to retry the entire webhook if another side effect ran successfully.

My current workaround is for my webhook to return a 200, even if there was a problem with the request, flagging the error in our logs or another service. But it would be nice to continue to have the ability to use our processed event log to find issues with each trigger and not have these events appear to have run successfully.

Alternatively, we could have no retries, and examine the response from our errored triggers, and manually retry if needed. But this doesn't seem sustainable.

### Describe the solution you'd like

I could imagine some default retry logic that is exactly like what we have now, but someone could add other cases depending on a webhook's response code. This becomes pretty simple `IF 408 THEN retry after a minute; IF 401 THEN don't retry`. Additionally, it would be really helpful to see those error codes as a column on the processed event tab!

### Describe alternatives you've considered

Another way to fix my issue would be to make sure each webhook only does one thing. But this would mean I would need, say, multiple insert triggers on a single table to handle each side effect, instead of having a single insert webhook. I've considered splitting each into their own event trigger, but it feels like it would be hard to stay organized and appropriately name each trigger (and each webhook).

It's certainly possible that I am just building the wrong thing because its more convenient to me than doing it "the right way", and maybe this is more about rethinking the Event Trigger UI to think about production APIs that grow in complexity.

### If the feature is approved, would you be willing to submit a PR?

Depending on the scope of the change and the languages needed, I would love to contribute.