Implement lightweight OptimisticDependencyFunction<TKey> primitive.

[benjamn]

While just about any kind of dependency can be modeled with an OptimisticWrapperFunction<TArgs, TResult>, many sources of cache invalidation signals do not require the full machinery of wrapped functions: makeCacheKey, [un]subscribe functions, the ability to rerun the wrapped function to compute the latest value, and everything that comes with the internal Entry class.

Previously, these simpler use cases were handled by "disposable" wrapper functions, which were essentially just ordinary wrapper functions that never returned a value and could be recycled when they became orphans. Despite these restrictions, disposable wrapper functions were still just as expensive as full-featured wrapper functions, so we weren't really capitalizing on the opportunity to do less work.

For dependencies that will never have children of their own, and do not need to compute an expensive result, we can get away with something much simpler:

import { dirname } from "path";
import { readFileSync } from "fs";
import { wrap, dep } from "optimism";

const dependOnDirectory = dep<string>();

const optimisticReadFile = wrap((filePath: string) => {
  dependOnDirectory(dirname(filePath));
  return readFileSync(filePath, "utf8");
});

const contents = optimisticReadFile("path/to/some/file");
dependOnDirectory.dirty("path/to/some");

With this dependency logic, you can call dependOnDirectory.dirty(directoryPath) to dirty all cached optimisticReadFile results that previously depended on directoryPath (because the wrapped function called dependOnDirectory(dirname(filePath)) where dirname(filePath) === directoryPath).

Using the dep<TKey>() API makes sense when you can provide a single TKey value that uniquely identifies the dependency, rather than a series of arguments that need to be transformed by makeCacheKey.

Using dep also implies the dependency is not associated with a function that computes a value. Instead, the dependOnDirectory dependency exists purely to record dependencies via dependOnDirectory(directoryPath) so that dependOnDirectory.dirty(directoryPath) can be called at a later time to invalidate any/all enclosing computations.

Because these new OptimisticDependencyFunction<TKey> functions cannot have child dependencies of their own, they are appropriate for modeling leaves in your dependency graph/tree/DAG. Because these dependencies are lighter-weight than wrapped functions, you should see significant performance benefits from handling your leaves in this way.