Add caching: the Spring cache abstraction, keys, eviction timing and the self-invocation trap

A Spring Boot 4.1.1 module whose test suite is the evidence for the article: 19 tests
producing 22 transcripts under docs/output/, plus 12 documentation chapters.

Findings the build pins:
- @EnableCaching has no exposeProxy attribute; the widely-copied
  @EnableCaching(exposeProxy = true) does not compile.
- Two methods sharing a cache name and an argument type share a key space, and one
  silently serves the other's answers.
- beforeInvocation = true is NOT deferred by TransactionAwareCacheManagerProxy on
  7.0.9 - doEvict picks evictIfPresent, which the decorator does not intercept.
- Four of five invalid declarations start a clean context and throw at the first call.
- Caffeine on the classpath silently displaces the simple provider.

caching/docs/output/03-self-invocation.txt

@@ -0,0 +1,13 @@
+# Four ways to call a @Cacheable method, one of which caches nothing
+
+injected bean class : com.ankurm.caching.selfinvocation.CatalogService$$SpringCGLIB$$0
+is an AOP proxy?    : true
+is a CGLIB proxy?   : true
+target class        : com.ankurm.caching.selfinvocation.CatalogService
+
+Four ISBNs, two of them repeats. A working cache does 2 lookups, not 4.
+
+this.lookup(..)                 -> 4 repository calls   <- no caching at all
+self.getObject().lookup(..)     -> 2 repository calls
+AopContext.currentProxy()       -> 2 repository calls
+a second bean calls lookup(..)  -> 2 repository calls