Refactor gamm hooks to handle error instead of panics

[Anmol1696]

Part of: #2520

What is the purpose of the change

• GAMM hooks deal with errors by panicing on errors, handle errors in the hook functions.
• Hooks errors can now be handled with ApplyFuncIfNoError
• This implementation allows hooks interface functions to return an error.
• If functions return an error any state changes will not be written to the state.

Brief Changelog

• Update the interface for GAMM hooks, to add return type error

type GammHooks interface {
  AfterPoolCreated(ctx sdk.Context, sender sdk.AccAddress, poolId uint64) error
  AfterJoinPool(ctx sdk.Context, sender sdk.AccAddress, poolId uint64, enterCoins sdk.Coins, shareOutAmount sdk.Int) error
  AfterExitPool(ctx sdk.Context, sender sdk.AccAddress, poolId uint64, shareInAmount sdk.Int, exitCoins sdk.Coins) error
  AfterSwap(ctx sdk.Context, sender sdk.AccAddress, poolId uint64, input sdk.Coins, output sdk.Coins) error
}

• Update methods that implement the GammHooks interface.

Testing and Verifying

• This change is a trivial rework / code cleanup without any test coverage.

Documentation and Release Note

• Does this pull request introduce a new feature or user-facing behavior changes? (yes / no)
• Is a relevant changelog entry added to the Unreleased section in CHANGELOG.md? (yes / no)
• How is the feature or change documented? (not applicable / specification (x/<module>/spec/) / Osmosis docs repo / not documented)

[ValarDragon]

So we can do this approach if panic(err) here for now

[ValarDragon]

If its alright, I'd like to close all but the mint hook switch for now.

This logic is pretty sensitive, and I'd prefer to not load too much state in refining this pretty brittle interface right now. Bez and I are working with Marko / SDK team to get more satisfactory framework-level answers for this problem, and would rather just reason about that + a switch.