RF: to allow for more flexible use

For now just "thinking out loud", I guess more specifics would come as I try...

- ATM the main use pattern is to decorate a function using `@cache.memoize_path` under assumption that path is the first positional argument. But it might not be the case in already existing code base, thus would require either
- creating use-case specific shims which would reorder/extract path from the corresponding function signature (could be in kwargs, or another positional arg), or even a value itself (e.g. in datalad it would be a dataset instance passed through from which we would get `.path`)
- providing some convenience, e.g. `path_getter(*args, **kwargs)` which if not defined, would be just current default `args[0]`

- if a `path_getter` above, and whenever we make it parametrized (e.g. for #5 #6 #10 ) -- should those be defined at the class level or at `memoize_path` invocation level? ATM we seems (actually I am a bit confused how we account for different functions...) allow for the same cache to be used across multiple functions. So if we are to allow that, it smells that for `path_getter` should be at invocation level since the same cache could be used across multiple invocations (functions)

- probably there is no non-decorator use pattern we need to provide, but we need to make sure that it works if we decorate a function instance right in the code, e.g.

```python
def func(path, ...):
...

def some(...):
out = cache.memoize_path(func)(path)
```
or especially either it would somehow work on locally defined functions/closures like

```python
def some(...):
def func(path, ...):
...
out = cache.memoize_path(func)(path)
```

and make sure that multiple invocations of `some` do take advantage of the cache from prior invocations

- if we do not foresee a use for `__call__`, should we just rename `memoize_path` -> `__call__`?