Optimize thread handling for feed DB requests

[xgi]

Each time you move over a feed in the menu, a new thread is created to load that feed's data from the database. If you move over many feeds (like simply holding the down arrow) then you can create many threads, spiking the CPU usage. Not many people likely have enough feeds for this to be a common concern, but it should be better handled.

Ideally we would just kill old threads after the user moves to a new feed, but that's not possible since they are generally just a single SQL command. Waiting to join each thread would be the same as waiting for them to complete. The solution I'm considering is having 3-ish "running slots" for threads which are allowed to run simultaneously. If a 4th thread is requested, it is added to a "holding" slot until a running slot opens. If a 5th thread is requested, it overwrites the 4th thread in the waiting slot. There can only be one waiting thread because realistically the user only needs one (the most recent one).

[plum]

I have suffered from very high spikes in in Castero, especially, it seems when accidentally loading a whole feed into the queue (and subsequently attempting to clear the queue with key-command 'c'); or so it seems.