Maintenance suggestion

As discussed by email with @jonhoo, some new IMAP libraries are really promising and may replace `imap` over time:

- [`imap-types`](https://github.com/duesee/imap-codec/tree/main/imap-types) and [`imap-codec`](https://github.com/duesee/imap-codec/tree/main/imap-codec): they can be considered a direct replacement of `imap-proto`. They provide solid types and codecs for dealing with IMAP requests and responses.
- [`imap-next`](https://github.com/duesee/imap-next): a thin [sans I/O](https://sans-io.readthedocs.io/) abstraction over IMAP's distinct protocol flows, based on `imap-{types,codec}`.
- [`imap-client`](https://github.com/pimalaya/imap-client): a direct replacement of `imap`. While it is already used in production by [Himalaya CLI](https://github.com/pimalaya/himalaya), it is not advised to use it yet as the API is not well defined nor documented. It may evolve towards a sans I/O structure. In this case, `imap` would become a first standard (blocking) I/O connector of `imap-client`. It would also open doors to async IMAP (tokio, async-std, smol etc).

I just initiate the thread now so we can discuss more about it when the final `imap-client` API design will start (within few months).

No repository files, tests, or entry points are identified. Start by reading the proposed imap-types, imap-codec, imap-next, and imap-client projects linked in the issue, then follow the discussion about the future API design. This is only complete once the project agrees on a concrete replacement plan and scope.

Written by the indexing model from the issue text.