refactor(docs): split monolithic api reference into multiple files

[elenakrittik]

Summary

This PR splits up the documentation into multiple files.

Fixes #392

Most pages now load in < 1s, instead of previous 20s.

Some info

Before The Split Up Thing

Clean build time (cd docs && time make html)

Executed in  190.83 secs    fish           external
   usr time  181.12 secs    0.00 millis  181.12 secs
   sys time    3.57 secs    3.86 millis    3.56 secs

After The Split Up Thing

Clean build time (cd docs && time make html)

Executed in  235.23 secs    fish           external
   usr time  219.04 secs    2.69 millis  219.04 secs
   sys time    4.56 secs    3.08 millis    4.55 secs

Largest files and their size

Before The Split Up Thing (find . -type f -printf '%s %p\n'|sort -nr|head -n 3)

5114195 ./api.html
1810495 ./ext/commands/api.html
540978 ./whats_new.html

After The Split Up Thing (find . -type f -printf '%s %p\n'|sort -nr|head -n 10)

999209 ./api/channels.html
811327 ./ext/commands/api/bots.html
561931 ./api/guild.html
548798 ./whats_new.html
490001 ./api/interactions.html
489654 ./genindex.html
469703 ./api/client.html
421717 ./api/message.html
349864 ./_static/api_redirect.js
307113 ./api/audit_log.html

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, ...)

[shiftinv]

@Victorsitou re: #722 (review)

1. In Enumerations, should we do:

.. attribute:: one

   Attribute one
.. attribute:: two

   Attribute two

or

.. attribute:: one

   Attribute one

.. attribute:: two

   Attribute two

Since this doesn't affect the output, it's mostly personal choice - i'd go with the second one. Either way, this isn't worth updating manually, so unless we introduce an .rst formatter, we should leave it as is.

2. In events that have on_x_create/update/delete, I suggest using that order, that is:

• :func:on_x_create(...) <disnake.on_x_create>

• :func:on_x_update(...) <disnake.on_x_update>

• :func:on_x_delete(...) <disnake.on_x_delete>

Updated in 627c038.
Some create/delete events are documented as one item, in which case it's not possible to add the update event inbetween them:

disnake/docs/api/events.rst

Lines 764 to 765 in 48c99b7

	.. function:: on_member_join(member)
	on_member_remove(member)

[shiftinv]

@onerandomusername re: #722 (comment)

Not sure where VoiceState should be documented, or VoiceRegion.

Old comment, but I've moved VoiceState to voice.rst in 48c99b7.

RawGuildMemberRemoveEvent should probably be documented in guilds.rst.

Keeping RawGuildMemberRemoveEvent in members.rst seems fine, since that also links to member events.
RawGuildScheduledEventUserActionEvent and RawIntegrationDeleteEvent are similar, and are also part of their respective pages instead of guilds.rst.

[Victorsitou]

Since this doesn't affect the output, it's mostly personal choice - i'd go with the second one. Either way, this isn't worth updating manually, so unless we introduce an .rst formatter, we should leave it as is.

👍

Updated in 627c038.

👍

[shiftinv]

Alrighty.

At this point, I've probably gone over all the changes several times, including comparing the old/new rst side-by-side today and updating anything that was missed.
Certainly took us a while, but I believe it's finally at a point where I'm comfortable merging it without second thoughts - it's not that it wasn't good before, but since documentation is a very core part of everything here, I prefer to quadruple-check that everything is in order :>

This has been a pretty monumental task, and I really appreciate @ItsAleph taking the initiative by creating this PR more than half a year ago and also implementing by far the biggest part of this whole endeavor.
It turned into more of a community project over time, with @onerandomusername (and me) updating parts of it and @Victorsitou and @Chromosomologist reviewing changes (thanks c:), but after 237 comments so far it's gotten to a point where anything that was potentially missed can be taken care of in another PR.

tl;dr:

[Victorsitou]

thank you very much to everyone who has contributed :)

[elenakrittik]

Thanks much to everyone! This wouldn't have been possible without your help!

[onerandomusername]

looks good. Any bugs that we find from this point onwards can be fixed in a separate pull request.