Implement max_concurrency support when starting shards

[mkrasnitski]

Supercedes #2650.

When a session is first kicked off and we need to start many shards, we can use the value of max_concurrency to kick off multiple shards in parallel, and do so in batches every 5 seconds. However, the contents of the batches need to be managed so that we don't accidentally get ratelimited.

Simply put, shards are ratelimited together if their IDs are equivalent modulo max_concurrency. For example, if max_concurrency is 16, then shards 0 and 16 get ratelimited together, and so do 1 and 17, etc. So, we need to make sure that a given batch doesn't include any conflicting shards that might cause the ratelimit to get hit. If we want a batch of maximal size, we need to wait until the queue contains enough shards to create a full batch.

However, we don't always want to wait for a batch to fill up if we know it's not possible for that to happen. This happens when we restart a single shard - in order to avoid waiting the 5 second loop timeout, we need to add a bool field to ShardQueuerMessage::Shard to signal whether we want to add the shard to the queue or not.

[GnomedDev]

I'm yet to test this out on my bot, but here's my first pass review.