Allow creating replication slots using multiple publications.

[reu]

Might not be a super common case, but it is one I have.

[vnvo]

Thanks!
Multiple publications is a legitimate use case and the core of this is right as far as I'm concerned.

I'd like a small design pass before merging, though:

1. Display doing SQL escaping. right now publication.to_string() yields the SQL-escaped form (e.g. pub''a). Display is meant to be human-readable, so this would produce confusing output if the config is ever logged. could we keep Display showing the natural pub1,pub2 and move the quote-escaping back to the SQL call site (or a dedicated to_sql_literal() method)? escaping reads more clearly next to the query construction anyway.

2. Ergonomics for the multi-publication case. the feature's whole point is >1 publication, but the only way to build that is FromIterator (["a","b"].into_iter().collect::<Publication>()), while new() and the struct field take impl Into<Publication> and there's no From<Vec<String>> / From<Vec<&str>> / From<[&str; N]>, so a collection can't be passed naturally. could we add those From impls (and maybe a .publications([...]) builder) so the common case is discoverable? It's extra work but I think it's worth it! :)

3. Publication is opaque. private field, no constructor, no accessor , but it's a public type in a public field, so users can't read back what they set. A pub fn new, as_slice()/iter(), or similar would help.

4. Empty list. Publication built from an empty iterator produces publication_names '', which Postgres rejects (i think) at stream start. Might be worth rejecting empty up front with a clear error.

5. Tests. Could you add a test covering 2+ publications and the quote-escaping behavior?

Also note: like #8, the publication field type change is breaking (struct-literal users + anyone reading config.publication as String), so this is a 0.4.0-type change. And heads-up that this conflicts with #8 in start_replication - if we land #8 first, this'll need a rebase.

This is a nice addition overall, I'd just like the API to be a bit more ergonomic and the escaping decoupled from Display first.