feature: Implement gateway ratelimit

[SubZero0]

Summary

This PR aims to add a ratelimiter to the gateway that currently has none except a Task.Delay(5000).
It follows what's described in the discord api docs.

Fixes #1442

Changes

• Add a new type of bucket, GatewayBucket
• Add IdentifyMaxConcurrency property to DiscordSocketConfig
• Add GetBotGatewayAsync to IDiscordClient
• Add session_start_limit to GetBotGatewayResponse
• Sharded client will automatically deal with concurrent identify requests when possible

[SubZero0]

I'll need to do a few more changes to this PR

[SubZero0]

After a bit more digging, I learned that the global queue is per-session, only Identify is per-account, and there's a "soft" presence update limit, so I changed my approach taking this into consideration.

• Added IdentifySemaphoreName and PresenceUpdate to GatewayLimits
• Gateway will use the same RequestQueue as REST per client, won't be sharing one anymore
• Identify will use a named semaphore (the name is changeable at GatewayLimits), this will make possible to share the same semaphore between clients with or without a sharded client

I also noticed (if I understood it correctly) that if the user hits the gateway ratelimit, it won't be able to send heartbeats and might end losing the gateway connection either way. It would be possible to create a reserved limit for it but do we want to interfere this much? @foxbot

[SubZero0]

While browsing the discord api docs github, I noticed this pull request: discord/discord-api-docs#1621

It seems discord provides a key that allows multiple shards to concurrently identify in Get Gateway Bot.

I'll see if there's a better way to implement it.

[SubZero0]

After some talk and more consideration, I reached the conclusion that Discord wouldn't change specific limits for the gateway since what needs to be changed is sent by REST (max concurrency) or can be solved by adding more shards (gateway global limits).

Taking this into consideration, I removed GatewayLimits.
I left the semaphore-related properties in DiscordSocketConfig, I'm also considering removing these since the limited use-case would be automatic identify control by independent DiscordSocketClients (without a DiscordShardedClient as mediator).

[SubZero0]

I decided to remove the named semaphore since it would add a lot more complexity. If someone is sharding for themselves, they have entire control when a client is going to identify.

Now only IdentifyMaxConcurrency is present at the config, since it's needed to create the "slave semaphores" for concurrent identify when automatic sharding is disabled.