feature request: Select::try_recv() for non-blocking check of multiple receivers

It would be nice to have a way to combine multiple receivers in a non-blocking way, rather than having to chain multiple `try_recv()` together, when checking multiple signals at once. Example: - `shutdown_rx: Receiver<()>` is a global shutdown signal - `abort_rx: Receiver<()>` is a struct local abort signal - I want to abort a spawned thread, TCP listener, whatever on either - I do not want to block the thread every check, even for a short delay Current pattern: ```rs if shutdown_rx.try_recv().is_ok() || abort_rx.try_recv().is_ok() { ... } ``` Not bad, but then one has to remember to do that everywhere (no compile-time guarantee). Forget once, and you "miss" a signal at that point in the code at runtime and 😕 . And for non-unit `Receiver<T>`, checking for one of them would be more complex. Whereas, instead, one could perhaps just pass the selector: ```rs let selector = Selector::new() .recv(&abort_rx, |msg| msg) .recv(&shutdown_rx, |msg| msg); // ... later, repeatable ... if selector.try_recv().is_ok() { ... } ``` I'm new to `flume` and not sure about all the lifetime issues, etc. this might introduce, but in theory, it seems like it might be fairly trivial compared to `Selector::wait()`, since `Receiver::try_recv()` should be true for all `Receiver<T>` -- the values would just be mapped by `Selector`. And not sure if the "fairness guarantee" would even be an issue since `Receiver::try_recv()` is non-blocking. Hope that makes sense. Caveat: `Select::try_recv(&self)` might be confused by users with `Select::recv(&self, ...)`, so maybe it was a design decision, but I think it would be useful anyway. Thanks! 😄