fix: remove support for overriding caches that break functionality

[ckohen]

Please describe the changes this PR makes and why it should be merged:

Discord.js is not meant to be cache independent in its current state. The option to override caches is provided but overriding some of these caches will cause major issues internally. Those caches are: GuildManager, ChannelManager, GuildChannelManager, RoleManager, and PermissionOverwriteManager.

⚠️ Overriding the cache for any of the managers listed above is now considered unsupported. Unsupported means you can still override said caches, but you do so at your own risk and will not receive help for doing so. Furthermore you will get a process warning when doing so to notify you of this DO NOT MESS WITH THESE CACHES IF YOU ARE NO 1000% SURE WHAT YOU ARE DOING

Status and versioning classification:

• Code changes have been tested against the Discord API, or there are no code changes
• I know how to update typings and have done so, or typings don't need updating
• This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

[advaith1]

wouldn't it be better to just put it in the docs and/or guide instead of also logging a warning? or at least add a way to disable the warning

and why do the typings say TODO: 🤔

[monbrey]

and why do the typings say TODO: 🤔

Because we need TODO things. Those managers are removed from the typings so as to discourage/prevent them from being overriden by cacheWithLimits/makeCache, but there is the intention to refactor things sufficiently such that those caches being empty does not break functionality.

[NotSugden]

why not just remove the functionality to override these caches then?

that makes more sense to me than adding a warning not to do it

[advaith1]

I disagree with totally removing it; you can still just not use the functionality it breaks if you want

[ckohen]

wouldn't it be better to just put it in the docs and/or guide instead of also logging a warning? or at least add a way to disable the warning

Although I did add it to the docs, the process warning is a much more present warning. It will only emit the warning once per process run, so up to 5 total warnings. It's more of a reminder like "hey, things are gonna break" and I don't want people just disabling the warning because they saw someone else do it.

why not just remove the functionality to override these caches then?
that makes more sense to me than adding a warning not to do it

Partially what advaith said, but also there's plenty of valid use cases. Maybe you only want to cache channels that can contain messages, that is perfectly fine to do, we just won't be able to support digging out all the little places of the library that break when you do that.
Side note: Not providing the GUILDS intent means none of these caches would be filled anyways, so there's another easy way to break it.

[kyranet]

Just one suggestion, but won't block.