Async signal handling API changes

Signal handling methods in zbus::azync::Proxy have some surprising quirks that I'm not sure are intentional. I also have some ideas about alternative APIs that might be of interest.

Current API quirks:

• Calling connect_foo() on a Proxy will register a callback, but this callback will never be called unless further actions are taken. This is not documented in the connect_foo generated docs except in a reference to connect_signal's docs.
• next_signal will return Some(Message) for all other messages on the Connection, only excluding the signals that were consumed by a connect_signal callback. Unless you have reason to know when the peer will be sending a signal, the only useful way to call this method is in a dedicated task that discards the Option and maybe acts on the errors.
• receive_foo() processes signals independently of connect_foo().

Suggested changes (one of the two):

1. Drop next_signal and make connect_foo start a task (on the Connection's executor) to receive signals. This is the behavior I expected given the docs. The task would be stopped when the Proxy is dropped or when the last connected signal is disconnected (using the SignalHandlerId).
2. Drop connect_signal completely and force the user to use receive_foo. This also cuts down on the API clutter of the generated objects, but it removes a maybe-useful feature.

Possible API additions / replacements:

Signal Enum:

• Add an enum of all possible signals (both normal and property-change) produced by a given Async*Proxy.
  • One enum variant per signal.
  • One enum variant per property, actually using the property's declared type.
  • Maybe a variant for "unknown signal sent with matching source/path/interface; here's the Message, have fun"
  • Maybe a variant for "I thought I knew what this signal was, but it didn't parse right"
• A proxy would either have a method that returns a Stream that produces values of this enum, or implement Stream itself with this as the item.

Starting a task that processes a SignalEnumStream<TheInterfaceEnum> and matches the resulting signals could be handled in the same way the user is currently expected to run next_signal streams, but will likely have easier access to any shared program state. This also avoids requiring Send closures/Futures unless the caller wants them to be Send.