Add hash of failed program in algod error message for created apps

## Problem

When an inner txn creates an application and that application's approval program fails, there is no way to identify which app actually failed from the error message returned by algod. This is problematic because the way most apps provide error messages is through an off-chain mapping of PC to error message (i.e ARC56). Currently for inner transactions clients can look at the app ID to determine which app failed and see if they have the PC mapping. For created app, however, there is no way to identify which app actually failed.

Snippet from a callback that handles errors in algokit (not yet committed):

```typescript
/**
* Make the given call and catch any errors, augmenting with debugging information before re-throwing.
*
* @param e The error thrown by the app call
* @param appSpec The appSpec for the outer app call that resulted in this error
* */
private handleCallErrors = async (e: Error, appSpec?: Arc56Contract) => {
// First check if the appSpec passed in matches this app
if (JSON.stringify(appSpec) != JSON.stringify(this.appSpec)) {
// If the app ID is 0, we have no way to determine what app this error corresponds to
// This means we can never detect inner-creation failures, because we don't have the app spec
// and we don't have the ID
if (this.appId == 0n) {
return e
}

const appIdString = `app=${this._appId.toString()}`
if (!e.message.includes(appIdString)) return e
}
```

## Solution

When a program fails, include the hash of the failed program in the error message

This is only really needed for new apps (and in particular, creations via inner txn)

## Dependencies

A performant non-crypto hashing algorithm, like [XXH3](https://github.com/zeebo/xxh3). Extrapolating from the benchmarks in the repo, an 8k program would be roughly ~1us per op, but with SSE2 (and I think it's safe to assume most Algorand nodes have SSE2 unless they are ARM) it'd be around ~400ns (and slightly faster with AVX2)

## Urgency

Not very urgent, but the decision of this would impact how the ecosystem at large handles errors. We might need to move to something like ARC65, which is on-chain error messages, if we cannot solve this scenario.