Rework caching, no longer cache html but cache expensive queries

[cojennin]

First pass at improving #505

Instead of caching the entirety of the html, cache some of the queries that go into building the post details screen (and aren't user dependent). I added about 300 posts to the calendar to check, and there are some small improvements. Have not seen any major performance degradation, though this function now goes uncached.

I'd prefer not to remove the cache in it's entirety without some further investigation, but this PR starts to untangle some of it from the calendar. I've also tried to improve some of the calls being made to other functions to eke out some small performance improvements, and consolidate some calls to functions that didn't seem necessary

Eventually, we could consider doing some things in future PR's like:

1. Limiting the posts that get rendered per day
2. Defer fetching details of a post until a user clicks the post
3. Rendering the initial post information (i.e., title and type) client side

[mjangda]

As discussed, this needs a bit more testing and profiling to see if this is a beneficial change (quick testing shows some benefits).

[jerclarke]

Really too bad this died on the vine, considering the bug it tries to fix is absolutely devastating to the trustworthiness of the calendar, and remains to this day.

Long shot but @cojennin, do you remember how bad the actual hit was of turning off caching v. leaving it on? Does it break the calendar? Because the bug currently caused by the per-user cache breaks the calendar.

[GaryJones]

Closing this PR as the underlying issue has been resolved differently.

Background

This PR attempted to fix #505 by reworking the caching strategy - caching expensive queries instead of the full HTML output. While this was a reasonable approach, further investigation (documented in #756) revealed that:

1. The caching wasn't providing meaningful performance benefits
2. The cache invalidation was fundamentally broken (keys didn't match between set and delete operations)
3. The real performance issue was the wp_dropdown_categories() calls for hierarchical taxonomies, not database queries

Resolution

• UPDATED: Disable calendar li_html_cache object cache entirely because it's buggy and the solution to performance problems isn't object caching #828 removed the broken li_html_cache entirely, solving the stale cache problem reported in Calendar: Object cache not cleared #505
• Calendar: Remove 'taxonomy hierarchical' from editable fields for performance and usability #757 made hierarchical taxonomies non-editable, solving the performance issue caused by loading full category trees for every post
• Calendar: Evolve post overlay into a Quick Edit modal for enhanced inline editing #829 proposes a future enhancement with AJAX-loaded modals that could implement proper caching if needed

The ideas in this PR (like deferring post details until click) are captured in #829 for future consideration.

Thank you @cojennin for the original investigation and approach - it helped inform the eventual solution!