refactor: Bot.load_extensions rework

[shiftinv]

Summary

This PR refactors Bot.load_extensions, improving several aspects and hopefully making common patterns easier to use.
Module discovery now works similar to pkgutil.walk_packages.

Initially I removed utils.search_directory entirely, but then opted to keep it for now and only deprecate it. While the transition to Bot.find_extensions (or even just Bot.load_extensions) should be trivial, having a deprecation period still won't hurt.

It might look like a lot, but most of it is documentation and tests :p

Docs can be found here https://disnake--796.org.readthedocs.build/en/796/ext/commands/extensions.html#ext-commands-extensions-load.

related: #1132

TODO

• make sure to clear up confusions between cwd and sys.path relative to main module

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 task lint
  • I have type-checked the code by running task 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, ...)

[Enegg]

Recently I've realized there are few ways of passing stuff around that doesn't involve slapping said stuff as bot attribute.
I could see a system where apart from accepting the client/bot instance in extensions' setup function, users could define extra arguments for the function of arbitrary type, which would be passed the relevant objects from the call to .load_extensions (probably as *args).
I reckon this would go into a separate PR but I am mentioning this here as it'd likely depend on this PR.

[shiftinv]

Recently I've realized there are few ways of passing stuff around that doesn't involve slapping said stuff as bot attribute. I could see a system where apart from accepting the client/bot instance in extensions' setup function, users could define extra arguments for the function of arbitrary type, which would be passed the relevant objects from the call to .load_extensions (probably as *args). I reckon this would go into a separate PR but I am mentioning this here as it'd likely depend on this PR.

That would be useful, yeah.
I'm sure people have different ideas for this, so it would warrant some more discussion about the specific design and to make sure common use cases are supported:

• pass arguments as dict or **kwargs to setup?
  • perhaps even parse the signature to only pass the declared subset of kwargs?
• how would it work with load_extensions, where the modules are not necessarily known ahead of time, and one may want to pass different arguments to different extensions?
• ...

(created a thread here: https://canary.discord.com/channels/808030843078836254/1092780323307257906)