Add internal alert ingest queue

Currently, every alert received via the API is sent directly to the internal memory store for alerts:

API: https://github.com/prometheus/alertmanager/blob/8ca1f66a2dd4bd97c1db9602342e6c4a135d5459/api/v2/api.go#L348

Memory store: https://github.com/prometheus/alertmanager/blob/8ca1f66a2dd4bd97c1db9602342e6c4a135d5459/provider/mem/mem.go#L149-L180

Every set locks the internal store, which can become a performance issue (cf. https://github.com/prometheus/alertmanager/issues/1201). Prometheus sends messages in batches of 50, but there's no enforcing of this on the alertmanager end. Anecdotally, I've seen a single alertmanager become unresponsive when receiving ~50 ingest requests per second, with each request containing a single message.

Batching at the store level is probably the right place to implement this:

https://github.com/prometheus/alertmanager/blob/8ca1f66a2dd4bd97c1db9602342e6c4a135d5459/store/store.go#L95

Adding a basic benchmark and a receive queue would be a good first step.

This is more or less inspired by common sense and being reminded of how kafka ingests messages.

Start with the API path in api/v2/api.go, the memory-store Set implementation in provider/mem/mem.go, and the store entry point in store/store.go. Review the locking behavior and existing issue context, then add a receive queue and a basic benchmark demonstrating the batching behavior and its completed performance impact.