Issue title: nodefs: allow Lookup to return new node for an existing name.
 Issue body: Consider a nodefs that is backed by some other NodeID based backend.  Eg.

   Dir 1, child "file" points to blob 2.

Now, if the backend executes an update, eg.

   Dir 1, child "file" points to blob 3.

and the backend / fuse have no polling/notification to communicate separate of FUSE events, the next kernel lookup for 

  Dir 1, "file" 

currently will do getattr on the existing node, which is tied to the node for blob 2. There is no way for an implementor to make this return the node for blob 3.

We can solve this by also calling Lookup for nodes that already exist.

This is incompatible as the existing behavior is equivalent to having the FS return fs.GetChild("file") if it is available, and most FS's probably don't implement this. Two solutions to that:

1. Add a flag to switch between these two behaviors.
2. Make a backwards incompatible change, and use the new fanciness of vgo to deal with this change.

 Comments: 
 Comment 0: @rfjakob - thoughts?
 Comment 1: re: incompatible changes: we can do the flag now, and flip the flag as an incompatible change. 
 Comment 2: https://github.com/hanwen/go-fuse/pull/217

for a POC.
 Comment 3: Sorry, I missed melissa04@example.net.

Question: If a kernel LOOKUP always calls Node.Lookup(), does nodefs need to track children at all?
 Comment 4: No, the node does not have to track children per se, but it's hard to imagine a FS that doesn't require tracking children in some form. Then the FS would also have to track parents (because the forget comes with NodeID rather than (parent, name) tuples.).

If we got rid of children in nodefs, we'd basically break existing users, and be exactly like the other fuse libraries.
 Comment 5: I agree. That logic would have to go into pathfs but it would break existing nodefs users.

About LookupKnownChildren, if the filesystem replaces a node, it has to call OnForget on the old node (if needed, but the testcase should probably show how to do it "right").

In any case, I'd go with the flag, and maybe keep it indefinitely.
 Comment 6: if the filesystem replaces a node on Lookup, it looks like the kernel immediately sends a FORGET for the node that was there (provided it was the last reference to that node.)  
 Comment 7: Oh, of course, a new NodeID is handed out to the kernel. That's pretty good actually.
{'source': 'GithubIssues', 'repo_name_with_owner': 'hanwen/go-fuse', 'issue_id': 317245945, 'repo_stars': 1614.0}