perf: batch cache (and some misc) optimizations

[v0idpwn]

Currently, BatchCache.put/2 always reads all pending messages and sorts them to detect overflow and discard the oldest messages. Since pending and in-flight messages are in the same table, it must filter to select only the pending ones.

This PR avoids the ets:select on every iteration by splitting pending and in-flight into two different tables. This allows us to use the size of the pending mesages ETS instead of selecting messages every time. I've considered a few different approaches (like using counters) but I felt like this was more straightforward.

When the batch is overflowing, it still runs the select and sort. So in case of a Logflare outage, #115 still sort of applies. But this should improve the performance when logflare is operational. In my tests, with a batch size of 100, the performance more than doubled, and memory was also decreased. I have added some stats in the commits. Notice that after I introduced the BatchServer, memory measurements must be done differently.

Some notes:

• I also implemented a BatchServer. It avoids concurrent flushes (which were a problem on LogflareLogger), and facilitated thinking about concurrency. It also ensures that LogflareLogger also has periodic flushes (which it didn't, only the backend had).
• Previously, flush was always sync. I made it async by default but sync if the pending list is at least a few batches big. Making it async by default allows it to handle more messages, but having a fallback to sync ensures it doesn't lose the backpressure that existed at this level.
• I also have a few commits for some small random optimizations. They don't necessarily make a significative difference, but they make us have less reductions/allocations and were trivial enough.