Replace the `TtlStoreValue` type on cached Versions/WellKnown with background refreshes.

We've keep tripping over this expiration in different places so it's time to fix it. Some examples have been:

• Conflicts between refreshing versions and refreshing the access token #5822 #5825 #5853 #5916
• Changes to the well-known's rtc_foci taking up to 7 days to be picked up by clients (admittedly we should be using the newer CS API endpoint for this now, but that would still involve caching a value) which became even more apparent after #5996 which had no immediate effect unless the cache was cleared.
• Discovered today: SyncServiceBuilder::build can fail with network related errors such as DNS resolution/Timeouts/Temporary server errors when checking server support for thread subscriptions. If we want good offline support in the SDK (and to handle poor connections gracefully) a Client and its associated services should really not be making network requests to be built and supply already cached data.

The solution (already been discussed with @bnjbvr a week or two ago) would be to remove TtlStoreValue and it's STALE_THRESHOLD and always return the cached value. Alongside this, we would need a mechanism that would make the relevant API calls in the background, caching any valid responses so that the next read is up to date. These background refreshes should ideally wait until any sync loops are running and up-to-date to avoid slowing down initial syncs and at the very least should be scheduled every time a Client is created (although ideally using something like SyncService::start to schedule the refreshes would help long-lived Clients to stay more up to date as apps get backgrounded and foregrounded).

Start by reading TtlStoreValue and STALE_THRESHOLD in crates/matrix-sdk-base/src/store/traits.rs, then trace SyncServiceBuilder::build and SyncService::start. Define how cached Versions and WellKnown are returned without expiration and how background refreshes are scheduled after sync or Client creation; done means valid responses refresh the cache without making Client or associated services fail on network errors.