fix(dependencies): register one fallback backend under concurrent first AppCache calls

[allen0099]

Closes #76.

Problem

get_app_cache is a sync dependency, so FastAPI runs it in worker threads. In an app that never configured a backend, concurrent first requests each built a MemoryBackend and a CacheManager. The later set() replaced the earlier one, so for a while requests used caches that could not see each other's entries.

Change

• New proxy.get_backend_or_fallback(): it returns the configured backend or registers a MemoryBackend. It re-checks under a threading.Lock, so every concurrent first caller gets the same instance.
• @cache uses the same helper instead of its own copy of the fallback. The dependency and the decorator can no longer install competing fallbacks, even when one runs on the event loop and the other in a worker thread.
• get_app_cache double-checks the manager under its own lock. It stays a sync dependency, so app.dependency_overrides users are unaffected.
• The fast path, where a backend or manager is already set, takes no lock.

Tests

• New test_get_app_cache_concurrent_first_calls_share_one_backend: 8 threads start together behind a barrier, with a slowed-down MemoryBackend constructor.
  • On the old code, the same test (patched at the old import site) fails with 8 == 1 managers.
  • With this change it passed 5 of 5 runs.
• Full suite: 521 passed and 146 skipped. The skips are the Redis/Memcached live suites; no test servers were running. Coverage is 92%.