updated error calls with module names

[alizahidraja]

Description

Included Module names in channel callback errors

closes: #1728

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests (does not apply)
• Updated relevant documentation (docs/) or specification (x/<module>/spec/) (does not apply)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[alizahidraja]

Will update the code to fix for issue raised by @colin-axner

Thanks @alizahidraja! Unfortunately with middleware, these error messages can be misleading. If we have a middleware stack which is ICS29 and ICS20, if ICS20 returns an error in the application callback, the final error message will actually indicate that the module which failed was fee-middleware (which is incorrect).

I think it might make more sense to include the portID? We could also change the notion of the "module" variable to be a "middleware stack", though it'd be nice to think this approach out fully

[alizahidraja]

I have mentioned both the portID & channelID in channel callback errors for better identification, lmk if that works

[colin-axner]

Thanks @alizahidraja for following up on my suggestion. I think this should help make the error message a bit more useful. Just left a minor suggestion on the error string formatting, but I don't have a strong preference here

[damiannolan]

Thanks @alizahidraja! LGTM 🚀

[chatton]

LGTM!