Leverage perforce revision "branch" information to implement lazy indexing

Our developers use private Sandboxes to create codelines for isolating work from primary development lines. Five or six of these sandbox codelines might be created in an average week, higher when developers roll onto new projects. Though these Sandboxes are in a different Perforce Depot, they are indexed as part of the same Fisheye Repository. When an individual developer branches 8k-17k files, Fisheye spends an inordinately long time (12-18 hours) indexing the change - apparently going through the laborious process of p4 print (see FE-227) on every file when it is known to be identical to the file it was branched from.

Perforce itself utilizes lazy copying so that only an rcs representation of the source file is retained and a reference to that versioned file is utilized. I would prefer to see Fisheye utilize a similar approach when perforce identifies that the revision in the change was created via a "branch" operation (or "move/add"), copying internal metadata from the internal metadata for the source revision (if part of the same fisheye repository) rather than recreating that data based on a p4 print of the changed revision in question.