1.0 Compatible Feed Loaders

[EricBAndrews]

Update feed loaders to use the new combined queries endpoint. This requires the Fetcher to check the API version and pick the appropriate endpoint in fetchCursor or fetchPage, which should be very straightforward.

We're not actually going to use the combined response, though, since our current system is much nicer:
Suppose, e.g., we use combined inbox queries and then need to load a new page of mentions because the user is scrolling the filtered view. To drive the mentions feed in a performant manner, we would still need a "child feed" construct that handles loading thresholds etc. This would be easy to handle as long as the user is scrolling the combined feed, since we would just tack on each new set of mentions, but the moment we need to load that new page of mentions things get ugly. We can:

• Keep hitting the combined endpoint until we get enough replies to show the user. This could cause the UI to respond very slowly depending on the content mix, and could result in a lot of wasted API calls
• Hit the mentions endpoint and add it to the child feed's items. When we go back to loading the combined feed, it will now fetch those mentions again and dedupe them out of the mentions feed, once again wasting API responses

Of those, the second seems plainly better given the UI responsiveness issue of the first, but I still don't see a great reason to implement it over our current system--especially since we still need that system for backwards compatibility and to support mixes Lemmy doesn't (e.g., applications + reports)

[EricBAndrews]

Per Slack, an exception case here is the PersonContentFeedLoader, which should take advantage of combined queries to support sort types for which the sorting value is obscured from the API response