Partial Pull Request for #13357

Summary of Changes

In a lot of places in the code, failing to read from the cache store should not result in an unrecoverable error state. This PR makes JMenuSite::load() resilient to cache related errors by catching exceptions implementing the new JCacheException interface and will try to still execute the database query to load the data instead.

The JCacheException interface is added to make it easier to implement exception handling for these classes. I elected an interface to not bind all exceptions explicitly to being subclasses of RuntimeException. So instead of having (currently) two catch blocks if you don't care the type of error you can just have this single block.

I explicitly catch the cache exceptions so we are explicitly aware the error condition is related to the cache failing to connect and not some other RuntimeException that gets thrown in the process (i.e. the database exceptions). I also only explicitly catch JDatabaseExceptionExecuting for the database side of the error handling since it is probably an unrecoverable error condition if the menus can't be used and frankly if any other type of RuntimeException is getting thrown at this point then there is a part of me that'd be surprised the code ran that far in normal use and there is a part of me that says this method isn't trying to handle all possible error conditions so only handle what it knows how to recover from.

Testing Instructions

If the cache store fails to connect or the cache configuration is bad, the exceptions thrown by the cache API should be caught and JMenuSite::load() try to manually execute the lambda function to load the data. A database query failure here should still result in the same error message being displayed. Other types of RuntimeException should now go uncaught and bubble up as this method isn't adequately suited to be a general error handler and now explicitly only deals with error types it can respond to.

Documentation Changes Required

N/A