Temporary Cache Data

To avoid things like #1202, I was thinking about how to "clean up" the `QSPreferredApplication` key in a more reliable way than simply removing it when the Open action is used (as in f5c80e793a7887622b2f60aa078c0cc8a951dda5). What if you use another action? What about all the other recent documents that you *didn't* open?

So I decided to cache the value for a limited time and unconditionally drop it, based on the way proxy objects are cached. That allows the feature to work, while reliably setting all objects back to normal after. There might be other approaches, so let me know if you have a better idea.

Once this was implemented, I thought of another use for temporary metadata. The other day, @tiennou and I were talking about the `details` method. Neither of us liked that it was trying the handler before trying the cache. I figured we should just check the cache first, and try to make sure details were never cached if the handler ended up providing something. That way, objects relying on a handler for details would always fall through the cache test. But then the handler is still hit every time the method is called, which can be frequent.

With the new temporary metadata, we can still get real-time info from the handler, but cache it for a few seconds for rapid-fire requests for the same information.

I wonder if this should go to release as well, since at least one user has complained of a slow results list in B71, but personally, I can't see a performance difference.