feat: improved named prepared statements support

[v0idpwn]

Adds support for Prepared Statements through the Extended Query Protocol.

Concept

This PR implements the following architecture:

• ClientHandlers keep track of the prepared statements sent on them
• ClientHandlers update the prepared statement packets changing the statement names to "internal names" (this is necessary because clients may reuse the names in different connections)
• Prepared statement packets aren't sent directly to the db socket, but instead are sent to the DbHandler. Whenever the ClientHandler sends a bind packet to the DbHandler, it should also send the respective parse (which it has stored)
• DbHandler decides whether it needs to run "parse" or just "bind"
• DbHandler must intercept "parse" responses when the client didn't request them/it was made due to necessity
• DbHandler injects "parse" responses when the client requested a parse but it's not necessary

Parsing/decoding

• To be able to handle the prepared statement packets, ClientHandlers need to peek at every client packet (at least on transaction mode)
• To be able to intercept parse responses, DbHandler needs to peek at every server packet.
• For both ClientHandler and DbHandler, we can avoid decoding the whole payload/decode only what's necessary (generally, we only need tagging, except for the prepared statement payloads from which we need more data).
• The decoding means more CPU usage, and it could also mean that we will need to optimize the decoding routines a bit further.

Limits

• ClientHandlers and DbHandler have separate limits
• If trespassing a ClientHandler limit, an error is returned and the connection is closed
• If trespassing the DbHandler limit, a clean-up is triggered and a random set of prepared statements is dropped. This is transparent to the client. The only consequence for them is that some of their queries may need to be re-prepared.
• ClientHandler has a memory limit. Every client connection is limited to (currently) 1MB of parse statements.

Potential next steps

• Make it work with read replicas too
• Smarter prepared statement eviction on DbHandler. E.g.: using a LRU strategy to evict the prepared statements that weren't used recently.
• Configurable limits
• Performance improvements/reducing CPU usage

Additional features

• Added a simple feature flag system per tenant
• Added some inspect/packet debugging utilities

[v0idpwn]

Pushed some architecture changes. Instead of using Supavisor.Protocol.split_pkts/1, which requires buffering all packets, implemented Supavisor.Protocol.MessageStreamer, which allows us to buffer only the packets we need to handle. This helps a lot avoiding performance issues for large messages (such as COPY or big data rows).

Also did some refactoring for better splitting of responsibilities, and a feature flag for prepared statements.