Unstable support for multiple storage implementations

[lemon24]

At least two people asked about support for other database engines (https://github.com/lemon24/reader/issues/168#issuecomment-1378505241, https://github.com/lemon24/reader/discussions/324), so it's probably time for another iteration on https://github.com/lemon24/reader/issues/168.

This issue is to open up the Storage and Search interfaces, so others have a way of using alternative storages without monkeypatching, and without having to guess what the interfaces are. For now, we'll only focus on tightly-bound search (that depends on a specific storage).

Note that the Storage and Search internal APIs continue to remain unstable (for now).

To do:

• [x] extract Storage and Search into protocols
  • [x] document Storage and Search (copy implementation docstrings, if any)
  • [x] clean up API where needed (naming, positional-/keyword-only arguments)
  • [x] document additional types
  • [x] document known areas of instability
  • search context manager
  • non-bound search
  • possible removal of Search.enable()/disable() (per https://github.com/lemon24/reader/issues/323)
  • http_etag / http_last_updated unification
  • ...
• make_reader() improvements
  • [x] storage.default_search_cls
  • [x] document _storage argument (in the internal API docs)
• [x] FAQ item ("Can I use reader with a database other than SQLite?")
• [x] backwards (in)compatibility guidance (announce breaking changes in changelog)