Add `flush_rx_buffer` to `BusABC`

### Is your feature request related to a problem? Please describe.

This request relates to problems that can occur for certain hardware/OS combinations when users try to filter the CAN messages coming through the bus. If the interface in use supports driver-level filtering, and if the driver does not take steps to apply the filter to (or simply purge) already-received messages whenever a new filter is configured, then the caller of `set_filters` may end up with unwanted messages at the beginning of their collection, once they start collecting received messages. (Examples: #1708 and #1413.)

### Describe the solution you'd like

Even aside from the problem mentioned, I think it would be nice for a user of an interface to have a `flush_rx_buffer` facility that's a partner to the `flush_tx_buffer` already present in the `BusABC` interface definition.

Depending on circumstances, this may allow a user to avoid importing a lower-level python library specifically to accomplish that flushing a different way.

### Describe alternatives you've considered

### Additional context

I think that it might make sense to have two different phases to this work (e.g. two different PRs if not two different Issues).

1. Add `flush_rx_buffer` to the `BusABC` class and provide implementations for (some of) the existing interfaces. This will help users put workarounds in place for situations like #1708 without resorting to lower-level techniques like used in #1413. It's also good to have this facility in the interface for general purpose usage. Doing this up-front also allows developers of emerging interfaces to join the party early.
2. Devise the best way to integrate `flush_rx_buffer` in with the `Bus.set_filters` to prevent future problems of a similar nature to #1708 and #1413.