post-call fingerprinting mode

if a function can potentially effect the tree (especially if there were changes to it detected in pre-call fingerprinting), e.g. I am thinking about some datalad operation which would trigger `git annex init` call... then fingerprint which we estimated (largely to decide to either even proceed with calling the function) would no longer be valid. Sure thing we would discover that whenever we call that function again and just redo the function call, but I wonder if there would be some optimization if we redo fingerprinting (possibly in background ,thus relates to #7) after the function call. I guess some timing to be made and target clear use cases which would benefit to be identified first.

No files or tests are named. Start by reviewing the existing pre-call fingerprinting flow and the related background-work discussion in issue #7, then identify concrete use cases such as a DataLad operation invoking `git annex init`; done means deciding whether post-call or background refingerprinting provides a worthwhile, measurable optimization.

Written by the indexing model from the issue text.