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/10-nulls.txt

@@ -0,0 +1,16 @@
+# A cached null is a real entry called NullValue
+
+searchCachingNulls("xyz") returns null, called twice -> 1 invocations
+
+  cache "nulls":
+    key xyz        ->  null   [org.springframework.cache.support.NullValue]
+
+The abstraction stores org.springframework.cache.support.NullValue.INSTANCE
+so a hit on null is distinguishable from a miss. This is usually what you
+want - it is the cheap defence against a hot lookup for a row that is not
+there - and occasionally exactly what you do not want.
+
+--- unless = "#result == null" ---
+searchNullable("xyz") twice -> 2 invocations   <- the null was never stored
+  cache "terms":
+    (empty)