Add support for per‑operation dynamic TTL per store in `cacheable` / `cache-manager`

[DanhezCode]

Description / Motivation:
I am aware that each store (e.g. Keyv instance) can be configured with its own default TTL. However, this is not sufficient because when I override TTL in an operation (set, wrap, getOrSet), the same TTL is applied to all stores. This means I lose the differentiation between stores: memory, Redis, and DB all get the same TTL.

What I need is fine‑grained control so that each key can have TTLs that vary per store, independently of the default TTL, and configurable per operation. This would allow me to cache different elements with different TTLs, while still respecting that each store should have its own TTL logic.

Problem:

• Default TTL per store works, but it prevents storing keys with different TTLs in the same store.
• Overriding TTL per operation currently applies the same TTL to all stores, which is not practical.
• I need per‑operation overrides so that each set, wrap, or getOrSet can decide a TTL per store for that specific key.
• Example: one key cached in memory for 10s, Redis for 5min, DB for 1 day; another key cached in memory for 1s, Redis for 30s, DB for 10min.

Possible Solutions:

1. Function‑based TTL per operation
   Allow ttl to accept either a number or a function ( value, store ) => number.

   • This would let developers compute TTL dynamically based on the store and/or the cached value.
   • More customizable, but requires stores to have identifiers or names to differentiate them.

2. Threshold multiplier per store
   Each store (Keyv instance or Cacheable store) could accept a ttlThreshold (a percentage between 0 and 1).

   • The effective TTL would be baseTtl * threshold.
   • Easier to implement, no need for store names.
   • Less customizable, since it’s only a scaling factor.

3. Per‑store TTL override function (overrideTtl)
   Each store could optionally define an overrideTtl function with a signature like:

   overrideTtl?: (ttl: number, value: T, remainingTime?: number) => number;

   • When a TTL is passed in a set or wrap, each store would call its own overrideTtl to adjust the TTL.
   • Example: if I call set(key, value, ttl=10), memory might override to 10s, Redis to 60s, DB to 1h.
   • This keeps per‑operation flexibility while letting each store enforce its own TTL logic.

Conclusion:
Adding support for dynamic TTL per store per operation (beyond the static default TTL) would make cache hierarchies much more flexible and realistic, especially in multi‑layer setups like [memory, Redis, DB]. It would also allow storing keys with different TTLs in the same store instance, configurable per operation, which is currently not possible.

Happy to PR if you're up for it.