feat(commands.cog): pass errors raised by cog_unload to the bot's on_error

[Snipy7374]

Summary

• Closes cog unload error logging #1046

Checklist

• If code changes were made, then they have been tested
  • I have updated the documentation to reflect the changes
  • I have formatted the code properly by running pdm lint
  • I have type-checked the code by running pdm pyright
• This PR fixes an issue
• This PR adds something new (e.g. new method or parameters)
• This PR is a breaking change (e.g. methods or parameters removed/renamed)
• This PR is not a code change (e.g. documentation, README, ...)

[shiftinv]

This would be a breaking change, since the exception info in this case is no longer available through sys.exc_info() as documented. The exception handler here could use a logger directly, like e.g. CommonBotBase.close

[Snipy7374]

This would be a breaking change, since the exception info in this case is no longer available through sys.exc_info() as documented. The exception handler here could use a logger directly, like e.g. CommonBotBase.close

so if you don't have a logger setted up then you don't see the error?

the original issue was a feature requesting to pass the error in the on_error event, if we use a logger to log the error should we also pass the error in the on_error? even if it prints NoneType: None or should we pass it in the on_error but ignore it when printing errors?

[shiftinv]

so if you don't have a logger setted up then you don't see the error?

The root logger uses the WARNING level by default, so log.error and log.warning show up unless manually disabled

the original issue was a feature requesting to pass the error in the on_error event, if we use a logger to log the error should we also pass the error in the on_error? even if it prints NoneType: None or should we pass it in the on_error but ignore it when printing errors?

passing it into on_error would be weird/inconsistent, since it's meant for errors related to events. I'd say just logging it here is fine